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.
