http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> 2013-03-27 09:40:16 UTC --- (In reply to comment #3) > (In reply to comment #2) > > Hmm, yes indeed it is the -freorder-blocks option. One solution is to > > disallow after reload for SEH-target to modify jumps. > > That's an awfully big hammer. Perhaps it's possible to first analyze > what is actually happening in bbreorder that causes this bug? Well, the issue is analyzed. The issue is that SEH is table-based EH, and so after bb-reorder used labels for describing eh-regions are getting invalid. If you take a look to the produces assembly for the example, you will notice that easily. I admit that the first patch is a bit too invasive, as it disables bb-reorder in all cases. But in fact we need to disable it just if there is a catch-region. A more improved variant is: Index: i386.c =================================================================== --- i386.c (Revision 197118) +++ i386.c (Arbeitskopie) @@ -3941,6 +3941,20 @@ register_pass (&insert_vzeroupper_info); } +/* Implement TARGET_CANNOT_MODIFY_JUMPS_P. */ +static bool +ix86_cannot_modify_jumps_p (void) +{ + if (TARGET_SEH && reload_completed + && cfun && cfun->eh + && cfun->eh->region_tree) + return true; + return false; +} + +#undef TARGET_CANNOT_MODIFY_JUMPS_P +#define TARGET_CANNOT_MODIFY_JUMPS_P ix86_cannot_modify_jumps_p + /* Update register usage after having seen the compiler flags. */ static void