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

Reply via email to