https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #8 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #7)
> > I still think that the profiling counter increment in the
> > __builtin_unreachable() path is a bug.
>
> How so? I only see a missed optimization, but with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #7 from Eric Botcazou ---
> This nop behaviour could be a bit inconsistent across architectures. For
> example, arm and powerpc don't generate a nop here.
Well, it's low-level trickery so architecture-dependent by definition.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #6 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #5)
> static void
> sparc_asm_function_epilogue (FILE *file)
> {
> /* If the last two instructions of a function are "call foo; dslot;"
> the return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #4 from Sebastian Huber ---
(In reply to Andrew Pinski from comment #3)
> Is the nop due to alignment?
With -g and -coverage I get this code:
sparc-rtems7-gcc -O2 -o - -S unreachable.c -fverbose-asm -g -coverage
.file
