https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-01-26
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=84047
     Ever confirmed|0                           |1

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed.

FWIW, my patch for 84047 does not fix this PR, as VRP never sees the
problematic instruction and is not able to warn.  This is because ccp2 has
removed the instruction.

Before ccp2 we had:

fstatic_array ()
{
  static struct A a = {.a={1, 2, 3}};
  int _2;

  <bb 2> [local count: 1073741825]:
  _2 = a.a[7];
  return _2;
}

After ccp2 we have:

fstatic_array ()
{
  static struct A a = {.a={1, 2, 3}};

  <bb 2> [local count: 1073741825]:
  return 0;
}

I'm not a language lawyer, so I don't know what the semantics of undefined
behavior is.  Is returning 0 even the correct thing to do?

Though perhaps, as Jakub mentions in pr84047, maybe we should move this GCC 9?

Reply via email to