volatile int causes inline assembly build failure

Bug #675347 reported by Michael Hope on 2010-11-14
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Linaro GCC
Fix Released
Andrew Stubbs
Linaro GCC Tracking
Fix Released
Andrew Stubbs
gcc-4.5 (Ubuntu)
Canonical Foundations Team
Canonical Foundations Team
gcc-4.6 (Ubuntu)

Bug Description

The attached code builds under 2010.10 but fails under 2010.11 with the following errors:

       atomic.cc: In function 'int foo(QBasicAtomicInt&)':
       atomic.cc:24:24: error: output number 2 not directly addressable
       atomic.cc:24:24: warning: use of memory input without lvalue in asm operand 4 is deprecated

Removing the 'volatile' from volatile int _q_value causes the problem to go away.

Related branches

Andrew Stubbs (community): Approve on 2011-04-05
Linaro Toolchain Builder: Approve on 2011-03-25
Andrew Stubbs (community): Approve on 2011-04-14
Linaro Toolchain Builder: Approve on 2011-03-24
Michael Hope (michaelh1) wrote :
Michael Hope (michaelh1) wrote :

A more complete log:

michaelh@pavo1:~/linaro/bugs$ ~/toolchains/gcc-linaro-4.5-2010.11-0-armv7l-maverick-cbuild14-pavo3/bin/g++ -O2 -Wall -save-temps -mfpu=neon -c atomic.cc
atomic.cc: In function 'int foo(QBasicAtomicInt&)':
atomic.cc:24:24: error: output number 2 not directly addressable
atomic.cc:24:24: warning: use of memory input without lvalue in asm operand 4 is deprecated

Michael Hope (michaelh1) on 2010-11-15
Changed in gcc-linaro:
assignee: nobody → Julian Brown (julian-codesourcery)
Scott Kitterman (kitterman) wrote :

This regression is blocking progress on getting Qt/KDE built on arm.

Changed in gcc-4.5 (Ubuntu):
importance: Undecided → High
Changed in gcc-4.5 (Ubuntu Natty):
milestone: none → natty-alpha-1
Scott Kitterman (kitterman) wrote :

Confirmed this as a regression in Ubuntu's gcc-4.5 4.5.1-10ubuntu1 (which uses Linaro's 2010.11). I'm currently building with 4.5.1-9ubuntu1 (which contains 2010.10) and am wll past where the newer one fails.

Changed in gcc-4.5 (Ubuntu Natty):
status: New → Confirmed
tags: added: patch

FAOD, we don't yet have a patch to fix this issue, do we?

tags: removed: patch
Scott Kitterman (kitterman) wrote :

Confirmed still a problem with qt4-x11 4.7.1 uploaded to Natty today.

I've not found a fix for this yet, but I think I have a workaround. Could you try compiling with "-fno-strict-volatile-bitfields" and let me know how you get on, please?



Scott Kitterman (kitterman) wrote :

make[2]: Entering directory `/tmp/buildd/qt4-x11-4.7.1/qmake'
g++ -c -o project.o -pipe -DQMAKE_OPENSOURCE_EDITION -O2 -fno-strict-volatile-bitfields -fno-strict-volatile-bitfields -I. -Igenerators -Igenerators/unix -Igenerators/win32 -Igenerators/mac -Igenerators/symbian -I/tmp/buildd/qt4-x11-4.7.1/include -I/tmp/buildd/qt4-x11-4.7.1/include/QtCore -I/tmp/buildd/qt4-x11-4.7.1/src/corelib/global -I/tmp/buildd/qt4-x11-4.7.1/src/corelib/xml -I/tmp/buildd/qt4-x11-4.7.1/tools/shared -DQT_NO_PCRE -DQT_BUILD_QMAKE -DQT_BOOTSTRAPPED -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_COMPONENT -DQT_NO_STL -DQT_NO_COMPRESS -I/tmp/buildd/qt4-x11-4.7.1/mkspecs/linux-g++ -DHAVE_QCONFIG_CPP -DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT project.cpp
g++ -c -o property.o -pipe -DQMAKE_OPENSOURCE_EDITION -O2 -fno-strict-volatile-bitfields -fno-strict-volatile-bitfields -I. -Igenerators -Igenerators/unix -Igenerators/win32 -Igenerators/mac -Igenerators/symbian -I/tmp/buildd/qt4-x11-4.7.1/include -I/tmp/buildd/qt4-x11-4.7.1/include/QtCore -I/tmp/buildd/qt4-x11-4.7.1/src/corelib/global -I/tmp/buildd/qt4-x11-4.7.1/src/corelib/xml -I/tmp/buildd/qt4-x11-4.7.1/tools/shared -DQT_NO_PCRE -DQT_BUILD_QMAKE -DQT_BOOTSTRAPPED -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_COMPONENT -DQT_NO_STL -DQT_NO_COMPRESS -I/tmp/buildd/qt4-x11-4.7.1/mkspecs/linux-g++ -DHAVE_QCONFIG_CPP -DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT property.cpp
cc1plus: error: unrecognized command line option "-fno-strict-volatile-bitfields"
cc1plus: error: unrecognized command line option "-fno-strict-volatile-bitfields"
ICECC[20202] 19:58:18: Compiled on
make[2]: *** [property.o] Error 1
make[2]: Leaving directory `/tmp/buildd/qt4-x11-4.7.1/qmake'
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory `/tmp/buildd/qt4-x11-4.7.1'
make: *** [build] Error 2

To do the build I changed:

--- a/mkspecs/linux-g++/qmake.conf
+++ b/mkspecs/linux-g++/qmake.conf
@@ -12,3 +12,8 @@ QMAKE_INCREMENTAL_STYLE = sublib
+ QMAKE_CFLAGS_RELEASE += -fno-strict-volatile-bitfields
+ QMAKE_CXXFLAGS_RELEASE += -fno-strict-volatile-bitfields

Is that correct?

Oh, that's really strange. Are you sure you're using the same G++ version which was previously failing with the inline-asm error?

Scott Kitterman (kitterman) wrote :

Yes. gcc-4.5 hasn't changed.

Your QT build must be picking up the wrong compiler:

mavis% g++-4.5 -O2 -save-temps -mfpu=neon -c atomic.cc
atomic.cc: In function 'int foo(QBasicAtomicInt&)':
atomic.cc:25:35: error: output number 2 not directly addressable
atomic.cc:25:35: warning: use of memory input without lvalue in asm operand 4 is deprecated
mavis% g++-4.5 -O2 -save-temps -mfpu=neon -c atomic.cc -fno-strict-volatile-bitfields
mavis% g++-4.5 --version
g++-4.5 (Ubuntu/Linaro 4.5.1-10ubuntu1) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

Can you please double-check?

BTW, for me g++ refers to a 4.4 compiler:

mavis% g++ --version
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

mavis% g++ -O2 -save-temps -mfpu=neon -c atomic.cc -fno-strict-volatile-bitfields
cc1plus: error: unrecognized command line option "-fno-strict-volatile-bitfields"

Scott Kitterman (kitterman) wrote :

# which g++
root@kubuntu-efikamx01:~/qt4-x11-4.7.1# /usr/lib/icecc/bin/g++ -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.1-10ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.1-10ubuntu1)

Scott Kitterman (kitterman) wrote :

Just to be sure, I reran the build in the same chroot without the change and got the same errors such as:

../../include/QtCore/../../src/corelib/arch/qatomic_armv6.h:119:35: error: output number 2 not directly addressable
../../include/QtCore/../../src/corelib/arch/qatomic_armv6.h:119:35: warning: use of memory input without lvalue in asm operand 4 is deprecated
../../include/QtCore/../../src/corelib/arch/qatomic_armv6.h:119:35: error: output number 2 not directly addressable
../../include/QtCore/../../src/corelib/arch/qatomic_armv6.h:119:35: warning: use of memory input without lvalue in asm operand 4 is deprecated

OK, looks like you're using a self-built GCC. The reference to the system G++ (/usr/bin/g++) for COLLECT_GCC is interesting: that might suggest a possible misconfiguration, and/or that the wrong binary is still being picked up for some phase of compilation, for some reason.

Maybe try one of the following:

1. Using the "official" build of 4.5.1-10ubuntu1 with -fno-strict-volatile-bitfields.

2. Adding "-v" to the CFLAGS/CXXFLAGS to see which binaries are actually being invoked.

Sorry for being stubborn, but if that flag doesn't work as a workaround, we're back to square one...

Scott Kitterman (kitterman) wrote :

Sure. I'll try it again with no icecc.

Scott Kitterman (kitterman) wrote :

Building now. I should know if the work around does it in an hour.

Scott Kitterman (kitterman) wrote :

The build is past where it worked before, so I'll call this progress.

Michael Hope (michaelh1) on 2010-11-18
Changed in gcc-linaro:
status: New → Confirmed
Michael Hope (michaelh1) on 2010-11-21
Changed in gcc-linaro:
status: Confirmed → In Progress
Matthias Klose (doko) wrote :

please no compiler upload before alpha-1 is out

Changed in gcc-4.5 (Ubuntu Natty):
milestone: natty-alpha-1 → natty-alpha-2
Scott Kitterman (kitterman) wrote :

So we'll just leave Qt/KDE broken for another month? That doesn't sound so
great either.

Incidentally I'd like to hear the upstream opinion on this patch before we apply it to our 4.5 tree, and especially before we deploy software using it.



Michael Hope (michaelh1) wrote :

Scott, Matthias: there's a work around by setting -fno-strict-volatile-bitfields but, due to this being inline assembler, the flag needs to be the default for anything that includes qatomic.h.

-fstrict-volatile-bitfields was added in 2010.11 so there's no loss in turning it off. Is there a way of setting this by default as a work-around?

Matthias Klose (doko) wrote :

adding "-fstrict-volatile-bitfields" would need touching every package again, which is not better. lets wait for feedback on the GCC fix.

Scott Kitterman (kitterman) wrote :

Could the g++ default be changed in gcc-defaults for now so we could get on
with things while the patch is being sorted?

The simplest way to achieve that at present is probably for Ubuntu (locally) to revert the patch:

2010-10-26 Jie Zhang <email address hidden>

        Issue #1259

        Backport from mainline:

        2010-10-26 Jie Zhang <email address hidden>

        * stor-layout.c (layout_decl): Use the field's type to
        determine the mode and keep DECL_BIT_FIELD for a volatile
        * config/arm/arm.c (arm_override_options): Default to

        2010-10-26 Jie Zhang <email address hidden>

        * gcc.target/arm/volatile-bitfields-1.c: New test.
        * gcc.target/arm/volatile-bitfields-2.c: New test.
        * gcc.target/arm/volatile-bitfields-3.c: New test.

Reverting the arm.c fragment should be enough. (This is Linaro GCC 4.5 rev 99425.)

Is that a possibility?

Dave Martin (dave-martin-arm) wrote :

I notice that _q_value is referenced twice in the constraints.

Can we get rid of the reference causing the problem, i.e.:

    asm volatile("0:\n"
                 "ldrex %[newValue], [%[_q_value]]\n"
                 "sub %[newValue], %[newValue], #1\n"
                 "strex %[result], %[newValue], [%[_q_value]]\n"
                 "teq %[result], #0\n"
                 "bne 0b\n"
                 : [newValue] "=&r" (newValue),
                   [result] "=&r" (result),
                 : [_q_value] "r" (&_q_value)
                 : "cc", "memory");

My understanding is that the "memory" clobber is enough to warn the compiler that that _q_value might be modified ... though I'm not a tool expert so I could be wrong there.

Alternatively, remove both constraints and just use "Q" instead. If we're actually using the constraint in instructions, "m" is wrong because we can't handle pre/post increment/decrement addressing, and no offset is allowed in ARM so "o" wouldn't be correct either:

    asm volatile("0:\n"
                 "ldrex %[newValue], %[_q_value]\n"
                 "sub %[newValue], %[newValue], #1\n"
                 "strex %[result], %[newValue], %[_q_value]\n"
                 "teq %[result], #0\n"
                 "bne 0b\n"
                 : [newValue] "=&r" (newValue),
                   [_q_value] "+Q" (_q_value),
                   [result] "=&r" (result),
                 :: "cc", "memory");

I don't have a suitable toolchain to test this with right now, though... can someone else see if it makes any difference?

Using 'Q' (as in the message I posted to the GCC list) seems to work, but still gives a warning rather than an error. That might be an acceptable workaround, I guess. (It's probably the correct thing to do anyway.)

Dave Martin (dave-martin-arm) wrote :


My 2c: since ISO C says volatile bitfields are wrong, then if any code needs -fno-strict-volatile-bitfields to build, then either that code is wrong (which is not obviously true in this case--- but if is it true I would like to understand how so we can avoid it), or ... the compiler is wrong.

Am I being too naive?


I'm pretty sure we're dealing with a compiler regression here: note that there isn't actually any usage of bitfields in the test case given (rather, it uses a volatile int), it just so happened that the code to implement -fstrict-volatile-bitfields caused a particular code path to be erroneously executed.

If things are working properly, the compilability of the code shouldn't be affected by the -f[no-]strict-volatile-bitfields options.

Marcin Juszkiewicz (hrw) wrote :
Scott Kitterman (kitterman) wrote :

No. That's caused by removing implicit-it=thumb from the default gcc config. There is another bug about that.

Changed in gcc-4.5 (Ubuntu Natty):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Michael Hope (michaelh1) wrote :

Oops. Saw another volatile bitfields patch and mis-read it as fixing this. Marked back as in progress.

Changed in gcc-linaro:
status: In Progress → Fix Committed
status: Fix Committed → In Progress
milestone: 4.5-2010.12-0 → 4.5-2011.01-0
Michael Hope (michaelh1) wrote :

Julian has pinged this.

Michael Hope (michaelh1) on 2011-01-05
Changed in gcc-linaro:
milestone: 4.5-2011.01-0 → 4.5-2011.02-0
Jamie Bennett (jamiebennett) wrote :

Please ensure that qt4-x11 is test built and verified with any fixes.

Matthias Klose (doko) wrote :

the current gcc-4.5 does revert the change from comment #26

Colin Watson (cjwatson) wrote :

Pushing to alpha-3, since the problem has been worked around as Matthias notes in comment 36.

Changed in gcc-4.5 (Ubuntu Natty):
milestone: natty-alpha-2 → natty-alpha-3
Michael Hope (michaelh1) wrote :

Still not landed upstream.

Changed in gcc-linaro:
milestone: 4.5-2011.02-0 → none
Martin Pitt (pitti) on 2011-03-01
Changed in gcc-4.5 (Ubuntu Natty):
milestone: natty-alpha-3 → ubuntu-11.04-beta-1
Michael Hope (michaelh1) wrote :

Still not landed upstream. Andrew, could you ask Julian to ping this again or push it upstream yourself?

Michael Hope (michaelh1) on 2011-03-16
Changed in gcc-linaro:
assignee: Julian Brown (julian-codesourcery) → Andrew Stubbs (ams-codesourcery)
Colin Watson (cjwatson) on 2011-03-18
Changed in gcc-4.5 (Ubuntu Natty):
milestone: ubuntu-11.04-beta-1 → none

Julian has now committed the patch upstream:


Launchpad Janitor (janitor) wrote :
Download full text (4.1 KiB)

This bug was fixed in the package gcc-4.5 - 4.5.2-7ubuntu1

gcc-4.5 (4.5.2-7ubuntu1) natty; urgency=low

  * Merge with Debian.

gcc-4.5 (4.5.2-7) unstable; urgency=low

  * Update to SVN 20110323 (r171351) from the gcc-4_5-branch.
    - Fix PR c++/47125, PR fortran/47348, PR libstdc++/48114,
      PR libfortran/48066, PR target/48171, PR target/47862.
      PR preprocessor/48192.

  [ Steve Langasek ]
  * Make dpkg-dev versioned build-dependency conditional on whether we want
    to build for multiarch.
  * Add a new patch, gcc-multiarch+biarch.diff, used only when building for
    multiarch to set our multilib paths to the correct relative directories.
  * debian/rules.defs: support turning on multiarch build by architecture;
    but don't enable this yet, we still need to wait for dpkg-dev.
  * When DEB_HOST_MULTIARCH is available (i.e., with the next dpkg upload),
    use it as our multiarch path.
  * debian/rules.d/binary-java.mk: jvm-exports path is /usr/lib/jvm-exports,
    not $(libdir)/jvm-exports.
  * OTOH, libgcj_bc *is* in $(libdir).
  * the spu build is not a multiarch build; look in the correct
    non-multiarch directory.
  * debian/rules2: pass --libdir also for stageX builds, needed in order to
    successfully build for multiarch.
  * debian/rules2: $(usr_lib) for a cross-build should not include the
    multiarch dir as part of the path.
  * debian/patches/gcc-multiarch+biarch.diff: restore the original intent of
    the patch, namely, that the multilib dir for the default variant is
    always equal to libdir (the multiarch dir), and we walk up the tree
    to find lib<qual> for the secondary variant.
  * debian/patches/gcc-multiarch+biarch32.diff: apply the same multilib
    directory rewriting for biarch paths with multiarch as we do without;
    still needed in the near term.
  * Put our list of patches in README.Debian.$(DEB_TARGET_ARCH) instead of
    in README.Debian, so that the individual files are architecture-neutral
    and play nicely with multiarch. LP: #737846.
  * Add a comment at the bottom of README.Debian with a pointer to the new
    file listing the patches.

  [ Loic Minier ]
  * Rework config/vxworks-dummy.h installation snippet to test
    DEB_TARGET_GNU_CPU against patterns close to the upstream ones (arm% mips%
    sh% sparc%) as to also install this header on other ports targetting the
    relevant upstream CPUs such as armhf. Add a comment pointing at the
    upstream bug.
  * Update __aeabi symbol handling to test whether DEB_TARGET_GNU_TYPE matches
    arm-linux-gnueabi% instead of testing whether DEB_TARGET_ARCH equals
    armel. Add a comment pointing at the Debian bug and indicating that this
    is only useful for older dpkg-dev versions.
  * debian/rules.def: fix "armel" entry to "arm" in list of
    DEB_TARGET_ARCH_CPUs for Debian experimental GCC 4.5/4.6 libraries.
  * debian/rules2: drop commented out GCC #42509 workaround as this was fixed
    upstream in 4.4+.
  * Change bogus DEB_TARGET_GNU_CPU test on armel and armhf to just test for
    arm as ths is what the Debian arm, armel and armhf port use.
  * Rework snippet setting armv7 on Debian armhf / Ubuntu to avoid


Changed in gcc-4.5 (Ubuntu Natty):
status: Confirmed → Fix Released

My backport of this patch appears to cause some test regressions caused by a compiler segmentation fault.

The 4.6 version is ok though:

Related: gcc-linaro/4.6,revno=106731

Changed in gcc-linaro-tracking:
assignee: nobody → Andrew Stubbs (ams-codesourcery)
milestone: none → 4.7.0
status: New → Fix Committed

Oops, bad syntax ...

Related: lp:gcc-linaro/4.6,revno=106731

I am out of the office until 17/04/2011.

Note: This is an automated response to your message "[Bug 675347] Re:
volatile int causes inline assembly build failure" sent on 14/4/2011

This is the only notification you will receive while this person is away.

Michael Hope (michaelh1) wrote :

Andrew, could you check the status of this ticket please?

The fix was committed to Linaro GCC yesterday.

Related: lp:gcc-linaro/4.5,revno=99493

Changed in gcc-linaro:
milestone: none → 4.5-2011.04-0
status: In Progress → Fix Committed
Michael Hope (michaelh1) on 2011-04-21
Changed in gcc-linaro:
status: Fix Committed → Fix Released
Matthias Klose (doko) wrote :

now seen again with gcc-4.6 in oneiric

I can't reproduce the problem with the original testcase. Is this a new problem?

Jean-Louis Dupond (dupondje) wrote :

The patch seems not applied in gcc-4.6 that we use?

The patch was committed here:


Does you compiler not have that?

On 05/06/2011 01:09 PM, Andrew Stubbs wrote:
> The patch was committed here:
> http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-
> linaro/4.6/revision/106731
> Does you compiler not have that?

no, currently using the fsf branch. and apparently not only seen on Ubuntu:


Michael Hope (michaelh1) wrote :

Looking at the comments the patch has landed in mainline but does not exist in GCC 4.6.0.

Matthias Klose (doko) wrote :

fixed in the gcc-4.6 package (oneiric, and unstable)

Changed in gcc-4.6 (Ubuntu Natty):
status: New → Invalid
Changed in gcc-4.6 (Ubuntu):
status: New → Fix Released
Changed in gcc-linaro-tracking:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.