https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #10 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #6) > So I did a quick audit of the EH_RETURN_HANDLER_RTX Yeah, me too. > and most are registers > rather than a memory location . And the ones which were memory locations > used either frame or stack pointer directly which seemed to not to be > removed. And those that with an address relative to hard_frame_pointer_rtx, marks the mem as volatile. > I had originally was going to record my findings but then I saw the > volatile for pa risc and deleted what I had wrote up. Ouch, "never delete what you can't undo". Sometimes you turn back another 180 degrees from your 180 turn in the middle of the analysis or bug-hunt. Was it more than a list of targets and their EH macros and patterns? The fun thing is that the dse1 pass (the culprit) works before pro/epilogue expansion, so it sees stores without the matching loads. That is, for targets that just define EH_RETURN_HANDLER_RTX (no eh_return pattern or any fancy extra) and handles EH at epilogue expansion time.
