https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82158
Peter Cordes <peter at cordes dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--- Comment #7 from Peter Cordes <peter at cordes dot ca> ---
(In reply to Ramana Radhakrishnan from comment #6)
> (In reply to Peter Cordes from comment #5)
> > That's what I thought; just be able to print backtraces. Good point about
> > -fno-exceptions. I forgot I was building as C in the first place. :P
>
> Yes and that's why I'm closing this as a WONTFIX.
Hang on, there's still a bug here for _Noreturn functions that *do* return.
That discussion established that the current behaviour is correct for actual
noreturn functions (thank you), but that's *not* what this bug report is about.
It's about this function:
void ext(void);
_Noreturn void foo(int *p, int y) {
ext();
*p = y; // then use args that had to survive a call
return;
}
gcc for ARM32 has a quality-of-implementation bug here: it only warns, and then
makes code that silently clobbers the caller's R5.
It's UB so the standard allows this, but it's definitely not nice, and can
cause problems that are hard to trace back to this function.
The valid options are:
* preserve the caller's registers as if _Noreturn hadn't been specified
* abort / trap at the end of the function instead of returning. (Enable
-mabort-on-noreturn by default?)
* compile-time error.
