volatile int causes inline assembly build failure

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

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

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.

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

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?

Thanks,

Julian

I have a test build in progress to try this.

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?

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

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

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

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

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

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

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

Patch posted upstream:

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

please no compiler upload before alpha-1 is out

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.

Thanks,

Julian

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?

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

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:

        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?

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

@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

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.

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

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

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

Julian has pinged this.

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

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

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

Still not landed upstream.

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

Julian has now committed the patch upstream:

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

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

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

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

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

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

now seen again with gcc-4.6 in oneiric

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

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

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

The patch was committed here:

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

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:

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

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

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