volatile int causes inline assembly build failure

[Michael Hope]

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.

[Michael Hope (michaelh1)]

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

[Scott Kitterman (kitterman)]

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

[Scott Kitterman (kitterman)]

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.

[Julian Brown (julian-codesourcery)]

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

[Scott Kitterman (kitterman)]

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

[Julian Brown (julian-codesourcery)]

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?

Thanks,

Julian

[Scott Kitterman (kitterman)]

I have a test build in progress to try this.

[Scott Kitterman (kitterman)]

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 192.168.111.110
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
 include(../common/g++.conf)
 include(../common/linux.conf)
 load(qt_config)
+
+
+ QMAKE_CFLAGS_RELEASE += -fno-strict-volatile-bitfields
+ QMAKE_CXXFLAGS_RELEASE += -fno-strict-volatile-bitfields
+

Is that correct?

[Julian Brown (julian-codesourcery)]

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)]

Yes. gcc-4.5 hasn't changed.

[Julian Brown (julian-codesourcery)]

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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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)]

# which g++
/usr/lib/icecc/bin/g++
root@kubuntu-efikamx01:~/qt4-x11-4.7.1# /usr/lib/icecc/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper
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)]

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

[Julian Brown (julian-codesourcery)]

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)]

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

[Scott Kitterman (kitterman)]

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

[Scott Kitterman (kitterman)]

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

[Julian Brown (julian-codesourcery)]

Patch posted upstream:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02245.html

[Matthias Klose (doko)]

please no compiler upload before alpha-1 is out

[Scott Kitterman (kitterman)]

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

[Julian Brown (julian-codesourcery)]

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.

Thanks,

Julian

[Michael Hope (michaelh1)]

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)]

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)]

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

[Julian Brown (julian-codesourcery)]

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:

        gcc/
        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
        bit-field.
        * config/arm/arm.c (arm_override_options): Default to
        -fstrict-volatile-bitfields.

        gcc/testsuite/
        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)]

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?

[Julian Brown (julian-codesourcery)]

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)]

@Julian

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?

Cheers
---Dave

[Julian Brown (julian-codesourcery)]

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)]

https://bugs.launchpad.net/bugs/682742 looks like similar issue

[Scott Kitterman (kitterman)]

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

[Michael Hope (michaelh1)]

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

[Michael Hope (michaelh1)]

Julian has pinged this.

[Jamie Bennett (jamiebennett)]

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

[Matthias Klose (doko)]

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

[Colin Watson (cjwatson)]

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

[Michael Hope (michaelh1)]

Still not landed upstream.

[Michael Hope (michaelh1)]

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

[Andrew Stubbs (ams-codesourcery)]

Julian has now committed the patch upstream:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01477.html

[Launchpad Janitor (janitor)]

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
...

[Andrew Stubbs (ams-codesourcery)]

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

[Andrew Stubbs (ams-codesourcery)]

The 4.6 version is ok though:

Related: gcc-linaro/4.6,revno=106731

[Andrew Stubbs (ams-codesourcery)]

Oops, bad syntax ...

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

[Ira Rosen (irar)]

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
18:29:27.

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

[Michael Hope (michaelh1)]

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

[Andrew Stubbs (ams-codesourcery)]

The fix was committed to Linaro GCC yesterday.

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

[Matthias Klose (doko)]

now seen again with gcc-4.6 in oneiric

[Andrew Stubbs (ams-codesourcery)]

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

[Jean-Louis Dupond (dupondje)]

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

[Jean-Louis Dupond (dupondje)]

For the error see: https://launchpadlibrarian.net/71179182/buildlog_ubuntu-oneiric-armel.doxygen_1.7.4-1_FAILEDTOBUILD.txt.gz

[Andrew Stubbs (ams-codesourcery)]

The patch was committed here:

http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6/revision/106731

Does you compiler not have that?

[Matthias Klose (doko)]

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:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625825

[Michael Hope (michaelh1)]

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

[Matthias Klose (doko)]

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