Re: gcc-2.95 OK, gcc-{3,4}.X not OK

[Andrew Haley <aph at redhat dot com>]

On 01/07/2010 10:37 PM, Andris Kalnozols wrote:
>>> On 01/03/2010 04:54 AM, Andris Kalnozols wrote:
>>
>>> Since multiple assignments are legal and evaluated from right
>>> to left, one could expect the following to work:
>>>
>>>   pcptr->code = pcptr = nop;
>>
>> On 01/03/2010 11:17 AM, Andrew Haley replied:
>>
>> I wouldn't.  :-)
> 
> OK, the problem was found, not by Valgrind nor Coverity, but the
> old fashioned method of inserting debugging statements in the code.
> 
> There are no coding nor compilation errors with either
> 
>   pcptr = pcptr->code = nop;
>     or
>   pcptr->code = pcptr = nop;
> 
> As long as the pointers are actually pointing to something,
> this is typical linked list processing.
> 
> There is a problem, however, when a global pointer structure is
> the assignment target of a function which itself may modify the
> global pointer.  The included test program gives the following
> output when compiled with gcc {3,4}.X:
> 
> 
>   ./gcc-bug
>   Take the suspect branch [1] or stay `safe' [2]? 1
>   Initialize `pcptr' with NULL [1] or malloc [2]? 1
> 
>   main:    [init] pcptr       = (nil)
> 
>   Taking branch 1.
>   fnc_A:          pcptr       = 0x8fff008
>                   pcptr->code = (nil)
>   Segmentation fault
> 
> 
>   ./gcc-bug
>   Take the suspect branch [1] or stay `safe' [2]? 1
>   Initialize `pcptr' with NULL [1] or malloc [2]? 2
> 
>   main:    [init] pcptr       = 0x8c39008
> 
>   Taking branch 1.
>   fnc_A:          pcptr       = 0x8c39018
>                   pcptr->code = (nil)
>   main:           pcptr       = 0x8c39018 (0x8c39018 <- should be this)
>                   pcptr->code = (nil)     (0x8c39018 <- should be this)
> 
> 
> Needless to say, the nature and duration of this behavior
> through the 3.X and current versions of gcc certainly seems
> to go against the Principle of Least Astonishment.

I'm sorry, this comment is too opaque for me to understand.  gcc
doesn't seem to be doing anything wrong.  The order of evaluation of
subexpressions is unspecified, sure, but that's how C has always
worked.  What is astonishing about it?

Andrew.