On Sat, Feb 5, 2011 at 4:55 PM, Ulrich Weigand <uweig...@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?
A bug? Can you file a bugreport and CC me? I'll look into the
problem.
Thanks,
Richard.
> Thanks,
> Ulrich
>
> --
> Dr. Ulrich Weigand
> GNU Toolchain for Linux on System z and Cell BE
> ulrich.weig...@de.ibm.com
>
