https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #3 from Jonathan Larmour <jifl-bugzilla at jifvik dot org> --- Thanks for the quick reply. (In reply to Jakub Jelinek from comment #2) > Not confirming since it is unclear even on what OS you are using this It's an embedded OS, so from your point of view, it's essentially bare metal. There are no included headers in the testcase so I'm not expecting the OS to make a difference in terms of generated asm. I would have expected any arm-none-eabi toolchain based on 7.3 would do the same thing as the one I built at least. > and > what to look for (I don't see r5 set close to start of main etc.). I attached the generated assembly file I get with --save-temps and the compile command line I provided (using -Os). You can see r5 being set on line 50 of that file. > That > said, if hal_setjmp works similarly to setjmp, but you don't actually tell > the compiler it has that behavior through __attribute__((__returns_twice__)) > and it doesn't have one of the standard setjmp names, like setjmp, > sigsetjmp, savectx, vfork or getcontext (with optional _ or __ prefixes), > then it surprises me if it works at all. Fortunately the semantics of hal_setjmp aren't relevant for the purposes of this bug - it's just a function call. Since the processor exception occurs when attempting to call myhandler2(), the longjmp() is never reached. In fact myhandler2() can be empty... perhaps I should have done that to emphasise that point, sorry. Thanks, Jifl
