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

Subject: Re: [Boost-build] Anyone know what's up with bug #7212?
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-08-29 11:07:32

   Hi all.

> On 29.08.2012 16:10, Kim Rasmussen wrote:
>> Ie. the output of
>>
>> ECHO /$(globalize)/ ;
>>
>> is
>>
>> /peek/
>>
>> and the output of
>>
>> ECHO /modules.$(globalize)/ ;
>>
>> is
>>
>> /modules.peek/
>
> Sounds like variable expansion is very, very, broken. I don't have any
> such problems on trunk, on Linux.
> Steven, any ideas?

   Kim & I have debugged the issue a bit.

   The problem seems to have been introduced by some of Steven's 
variable expansion changes but the effects are ***really really 
wierd***. :-) My guess is that the changed code is somehow triggering a 
compiler/optimizer bug.

   The problematic function in new code is expand(), located in the 
function.c module. In the original 1.49 Boost library release codebase, 
that function did not exist and its work seems to have been done by the 
var_string() function in the variable.c module (and possibly some other 
function in the later removed expand.c module - did not check).

   There we have a 'while ( --i >= 0 )' loop aroung the middle of that 
function which never seems to get entered on the target system. Wierd 
thing is that if we add the following code just before that while loop:

     if ( --i >= 0 ) { printf( "%d\n", i ); }
     ++i;

   Then everything works fine. :-)

   On the other hand, if we leave in the same code but without the 
printf() call - then we're back to the original problem - most likely 
due to the optimizer recognizing and removing the dummy code.

   Kim had to leave now for a while but will try to connect back in a 
few hours.

   I still have not done the following on the target system:
     - tried using the debug Boost Jam build
     - collected version information (Linux/gcc/glibc)

   The 'warning' problem mentioned in the bug ticket comments seems to 
be caused by the target system's include files (old version perhaps?) 
not declaring the strndup() function unless the _GNU_SOURCE symbol is 
defined, but that warning existed with Boost library 1.49 release and 
fixing it in the current trunk has no effect on the initial variable 
expansion problem. I'll fix that by rewriting the code to not use 
strndup() in the first place (will replace it with some 
malloc()/strncpy() combination).

   I'll try to rewrite the expand() function mentioned above to not use 
'goto', as my guess would be that this is confusing the optimizer and 
causing it to optimize away the whole 'while ( --i >= 0 )' loop. Steven, 
as you're the original author of this code - have any hints on why it 
was written so and ideas on what could be done to avoid this issue?

   Volodya, do you have any suggestions on how we can check whether this 
is the case? Some gdb magic perhaps? Or some gcc option to make it 
generate assembler code? If you'll be around in a few hours, can you 
give me a ping on ICQ?

   Best regards,
     Jurko Gospodnetić