Re: [Boost-build] Anyone know what's up with bug #7212?

Subject: Re: [Boost-build] Anyone know what's up with bug #7212?
From: Kim Rasmussen (rasmussen74_at_[hidden])
Date: 2012-08-29 16:31:02

Hi!

I have looked more into the problem and as far as I can see it is
clearly related to compiler optimization.
Below I have included all relevant information, so please accept my
apologies for the lengthy mail.

Target system information:

$ uname -a
Linux munin-4 2.6.16.60-0.69.1_1.0102.5650.2.2.74-ss #1 SMP Tue Dec 21
17:20:07 CST 2010 x86_64 x86_64 x86_64 GNU/Linux

$ g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/4.6.0/bin/../snos/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/4.6.0/snos/libexec/gcc/x86_64-suse-linux/4.6.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.6.0/configure
--prefix=/opt/gcc/4.6.0/snos --disable-nls
--libdir=/opt/gcc/4.6.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/4.6.0/snos/include/g++
--with-slibdir=/opt/gcc/4.6.0/snos/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit x86_64-suse-linux
--with-mpc=/opt/gcc/mpc/0.8.1 --with-mpfr=/opt/gcc/mpfr/2.4.2
--with-gmp=/opt/gcc/gmp/4.3.2 --with-sysroot=
Thread model: posix
gcc version 4.6.0 20110325 (Cray Inc.) (GCC)

As suggested by Jurko earlier today when we did a bit of debugging,
the following was tried on the trunk of Boost build.  All commands
below are executed within the v2/engine directory.

Now, the culprit appears to be the expand() function in function.c.
For testing we use a file, let's call it jamtest.jam, containing only
these lines:

local a = one two three ;
ECHO /$(a)/ ;

Then the following commands:

$ ./build.sh -d3 --release > /tmp/build-d3-release
$ ./bin.linuxx86_64/bjam -f jamtest.jam

gives

/one/
don't know how to make all
...found 1 target...
...can't find 1 target...

but

$ ./build.sh -d3 --debug > /tmp/build-d3-debug
$ ./bin.linuxx86_64.debug/bjam -f jamtest.jam

gives

/one/ /two/ /three/
don't know how to make all
...found 1 target...
...can't find 1 target...

which is what we expected -- so clearly, the 'release' version is
faulty. (BTW, the build-d3-release and build-d3-debug files can be
found in the pastebins  http://pastebin.com/M2njiNEK  and
http://pastebin.com/038qcgFF respectively).

Now, if we insert the following lines just before the line  "while ( --i >= 0)"

   if (--i >= 0) {
      side_effect = i;
   }
   ++i;

and add

   static int side_effect;

just before the function declaration, we then get:

$ ./build.sh -d3 --release > /tmp/build-d3-release
$ ./bin.linuxx86_64/bjam -f jamtest.jam
/one/ /two/ /three/
don't know how to make all
...found 1 target...
...can't find 1 target...

and

$ ./build.sh -d3 --debug > /tmp/build-d3-debug
$ ./bin.linuxx86_64.debug/bjam -f jamtest.jam
/one/ /two/ /three/
don't know how to make all
...found 1 target...
...can't find 1 target...

that is, correct in both release and debug modes.

To me, it smells compiler bug, but as this is a system where I cannot
"just update" the compiler, I am wondering if there are other
solutions.  I have a feeling that it is the loop/while/goto construct
that's complicating matters.

BTW, the problem is not present with Boost 1.49, but both in 1.51 and
trunk.  Of course, function.c is not present in 1.49, so that figures.

I'd __really__ like to get on 1.51, so any suggestions on how to
proceed are most welcome.

Best regards
Kim