https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274
--- Comment #2 from Tomas Kalibera <tomas.kalibera at gmail dot com> --- (In reply to Eric Botcazou from comment #1) > > -freorder-blocks-and-partition sometimes causes a function to end right in a > > (non-returning) call, but SEH needs at least one more instruction on x86_64. > > Seen in GCC 10.3, 11.2 and git master. Maybe [1] did not cover all the > > cases? > > SEH means "Structured Exception Handling" but there is no exception handling > in this chunk of program since it's written in C and compiled without > -fexceptions, so I'm not quite sure what you're expecting here. This also causes crashes with setjmp/longjmp only (no C++ exceptions, no explicit use of C-exceptions in the C code). R triggers unwinding via long jumps (explicitly calling longjmp in C, to implement error handling in R), of the frames between setjmp and longjmp. The unwinding sometimes crashes due to the problem reported, because it does not find the unwinding information for some frames. Windows looks for a function matching a given instruction pointer, which happens to be right after the call causing the long jump. However, when the function end is marked right after such a call (such as in the example), the instruction pointer is regarded past the function end, and hence it is not matched to the function it should be. We were using workarounds to disable SEH during unwinding, via redefining setjmp to __intrinsic_setjmpex((x), NULL), so using the NULL frame argument instead of the default __builtin_frame_address(0).
