Re: Wrong-code bug in execute_update_addresses_taken?

[Richard Guenther]

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

Re: Wrong-code bug in execute_update_addresses_taken?

[Ulrich Weigand]

Richard Guenther wrote:
 A bug?  Can you file a bugreport and CC me?  I'll look into the
 problem.

Sure, this is now PR tree-optimization/47621.

Thanks for looking into it!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Wrong-code bug in execute_update_addresses_taken?

[Ulrich Weigand]

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

Re: Wrong-code bug in execute_update_addresses_taken?

[H.J. Lu]

On Sat, Feb 5, 2011 at 7:55 AM, 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?


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

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


-- 
H.J.