Re: Wrong-code bug in execute_update_addresses_taken?

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sat, Feb 5, 2011 at 7:55 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Hello,
>
> the following program seems to be miscompiled at -O or higher:
>
> int
> main (void)
> {
> ?int data = 1;
>
> ?struct ptr
> ? ?{
> ? ? ?int val;
> ? ?} *ptr = (struct ptr *) &data;
>
> ?ptr->val = 0;
>
> ?return data;
> }
>
> This program should return 0, but actually returns 1.
>
> [ As far as I can tell, this program does not violate the aliasing
> ?rules; all memory accesses refer to an object of effective (because
> ?declared) type "int", and use lvalue references of type "int".
> ?The pointer cast might depend on implementation-defined behaviour,
> ?but is not undefined. ?In any case, there are no warnings, and use
> ?of -fno-strict-aliasing does not fix the problem. ?]
>
> In 024t.forwprop1, we still have (correctly):
>
> ?# .MEMD.3455_4 = VDEF <.MEMD.3455_3(D)>
> ?dataD.1975 = 1;
>
> ?# .MEMD.3455_5 = VDEF <.MEMD.3455_4>
> ?MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
>
> ?# VUSE <.MEMD.3455_5>
> ?D.3453_2 = dataD.1975;
> ?return D.3453_2;
>
> but then in 025t.ealias, we get:
>
> ?dataD.1975_4 = 1;
>
> ?# .MEMD.3455_5 = VDEF <.MEMD.3455_3(D)>
> ?MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
>
> ?D.3453_2 = dataD.1975_4;
> ?return D.3453_2;
>
> This is apparently caused by the "addresses taken" pass,
> which results in those messages:
>
> ?No longer having address taken: data
>
> ?Registering new PHI nodes in block #0
> ?Registering new PHI nodes in block #2
>
> ?Updating SSA information for statement data = 1;
> ?Updating SSA information for statement D.3453_2 = data;
>
> It seems that for some reason, the pass claims to be able to
> eliminate all statements that take the address of "data",
> but then leaves the MEM reference unchanged ...
>
> Any suggestions on what might cause this problem?
>

This behavior change of -fno-strict-aliasing is caused by

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00788.html


-- 
H.J.