Wrong-code bug in execute_update_addresses_taken?

[H.J. Lu]

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.