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

--- Comment #5 from Richard Henderson <rth at gcc dot gnu.org> 2011-08-11 
23:54:57 UTC ---
Tricky stuff, this.

The ICE is, for the most part, valid.  The transformation that
is being done in -fsched2-use-superblocks is invalid, from the
point of view of the unwind information.

That said, it's all about the presence of a frame pointer being
used in one portion of the function and not used in another portion.

Test #c0 uses non-local goto, which does Really Odd Things with
the frame pointer.  The non-local goto itself has totally wrong
unwind info.  It's no wonder we're confused there.

Test #c1 forces the use of a frame pointer that's not needed.

Test #c3 forces the use of an otherwise unneeded frame pointer
by using __builtin_return_address with a non-zero argument.
(Which really ought not work at all without -fno-omit-frame-pointer.)

In the near-term, -fsched2-use-superblocks ought to be taught
that an RTX_FRAME_RELATED_P insn has an anti-dependency on a
following branch.  That'll prevent the setup of the frame pointer
from "auto-shrink-wrapping" without additional fixups elsewhere.

Reply via email to