[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

["matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #16 from Michael Matz <matz at gcc dot gnu.org> ---
A general remark: in principle I don't see problems with undoing a little CSE,
as proposed.  I.e. for each SSA name use, see if it (trivially, or
conservatively
or optimistically) refers to an address of a tracked DECL, and include those
in the dont-share set.

But I will remark that this then handles code that was invalid to start with
as if it were valid, and I'm not sure if this will change diagnostics outcome
in any way (it certainly will prevent the slot sharing and hence any
diagnostics
that are based on such sharing to happen, e.g. when dirtying memory at
lifetime-end).

What I mean is the classic anti-pattern in C:

   char * ptr;
   {
     char localarray[n];
     dosomething (localarray);
     ptr = localarray;
   }
   domore (ptr);

The proposed solution will make the reference to the SSA name of 'ptr',
even though it was invalid in the source, keep localarray[] to be conflicting
and hence unshared with any other surrounding storage.

Depending on how PHI nodes are handled this will also mean that an SSA name
can't ever be un-associated with a DECL anymore:

  char * ptr = someotherarray;
  if (cond1)
  {
    char localarray[n];
    ptr = localarray;
    foo (ptr);
  }
  if (cond2) { char localarray[n]; ptr = localarray; foo(ptr); }
  if (!cond1 && !cond2)
    foo (ptr);

Here we will have a PHI for ptr: 'ptr_3 = PHI<ptr_1, ptr_2>'.  The question
is how the reference(s) to 'localarray' will be handled: does it lead to ptr_3
also referring to them or not.  I.e. usual question in PHI merging: optimistic
or pessimistic.

Note that the answer to the latter question might influence the whole
effectiveness of stack slot sharing.  IIRC the latter type of code was one
of the examples that explodes in stack usage without sharing (localarray[]
being instead local C++ objects; but I don't remember if references to them
could bleed out of scopes in the same way as above).