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.
