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? Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com