[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[jifl-bugzilla at jifvik dot org]

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