[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
So I see a few issues here.

First the copyprop pass does not discover new const/copies.  So if we have

  _2 = 344;
  ubound.0_3 = _2 & 7;
  size.1_4 = ubound.0_3 + 1;
  size.1_5 = MAX_EXPR <size.1_4, 0>;
  _6 = size.1_5 * 4;
  _7 = (character(kind=4)) _6;
  _8 = MAX_EXPR <_7, 1>;
  sizes_9 = __builtin_malloc (_8);
  size.3_10 = MAX_EXPR <ubound.0_3, 0>;
  _11 = size.3_10 * 4;
  _12 = (character(kind=4)) _11;
  _13 = MAX_EXPR <_12, 1>;
  strides_14 = __builtin_malloc (_13);
  MEM[(integer(kind=4)[0:D.1917] *)sizes_9][0] = 1;
  if (ubound.0_3 > 0)
    goto <bb 3>;
  else
    goto <bb 6>;

We discover _2 = 344 and copyprop that to its uses.  However, copyprop does not
discover that the RHS of ubound.0_3's assignment will simplify into a copy
until *after* the main copy propagation algorithm is complete.  ie, that isn't
discovered until subsitute_and_fold.   Basically anything that doesn't look
like a const/copy initialization when the pass starts is effectively ignored.

Durding substitute_and_fold, we substitute the value 344 for uses of _2.  But
we don't pick up that ubound.0_3 now has a propagatable value.  Worse yet,
because we walk backwards through the statements, even if we recorded that
ubound.0_3 has a propagatable value we wouldn't be able to utilize that
information.

What a mess.


My preference would be to enhance the copy propagation pass to discover these
secondary copies.  That would obviously slow down the pass as it's going to
have to look at a lot more statements and there'll be more statements to
reevaluate as values move through the lattice.

Another possibility would be to do some kind of post-processing after
substitute_and_fold to recognize that new const/copies were exposed and do
something sensible.