[Bug tree-optimization/58920] Overeager optimization based on TREE_THIS_NOTRAP

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #3)
> > The TREE_THIS_NOTRAP macro came up in email the other day, and it seemed to
> > me that it would be useful to set on C++ references, since they are required
> > to refer to objects; trying to read from a null reference gives undefined
> > behavior.  So I tried the attached patch.  But it breaks all the ext_pointer
> > tests in libstdc++.
> > 
> > Basically, what's happening is that there is a code path which is never
> > taken which leads to an explicit null dereference.  The optimizers see this
> > happening within a loop and decide to hoist it out of the loop.  So now it
> > is executed before the loop starts, and causes a SEGV.
> 
> If the dereference can generate a SEGV before being moved and nevertheless
> has the TREE_THIS_NOTRAP flag, then this is the bug and loop invariant
> motion does
> not make things worse.
> 
> As Andrew explained, you cannot set TREE_THIS_NOTRAP on all references.  In
> Ada,
> we set it only on parameters passed by reference, but it needs to be cleared
> during inlining because of this kind of issues.

"This kind of issues" is that GCC treats TREE_THIS_NOTRAP as applying
independent of the execution context.  That is, if you have

  if (p)
    *p = 0;

and mark *p with TREE_THIS_NOTRAP then GCC thinks *p will not trap
even when moved before the if (p) check.  So it has no concept of
"conditionally doesn't trap".

Though I thought that for C++ references that would be a non-issue.
As of pointer vs. reference types this shouldn't matter here as you
annotate actualy tcc_reference trees, not types.