Bug 94986 - missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm
Summary: missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2020-05-07 15:59 UTC by Arnd Bergmann
Modified: 2020-06-03 17:23 UTC (History)
4 users (show)

See Also:
Host:
Target: arm
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arnd Bergmann 2020-05-07 15:59:46 UTC
I reported a bug against clang for a Linux kernel failure, but 
 it was suggested that the clang behavior is probably correct in this corner case while gcc gets it wrong, see https://bugs.llvm.org/show_bug.cgi?id=45826

echo 'void f(void) { asm("mov r7, #0" ::: "r7"); }' | arm-linux-gnueabi-gcc -march=armv7-a -O2  -mthumb -pg -S -xc -

silently accepts an inline asm statement that clobbers the frame pointer, but gcc rejects the same code if any of '-O0', '-fomit-frame-pointer' or 'fno-omit-frame-pointer' are used:

<stdin>: In function 'f':
<stdin>:1:44: error: r7 cannot be used in 'asm' here

If using r7 in this case is indeed invalid, we need to ensure the kernel does not do this, and having gcc reject it would be helpful.
Comment 1 Wilco 2020-06-03 16:37:49 UTC
(In reply to Arnd Bergmann from comment #0)
> I reported a bug against clang for a Linux kernel failure, but 
>  it was suggested that the clang behavior is probably correct in this corner
> case while gcc gets it wrong, see https://bugs.llvm.org/show_bug.cgi?id=45826
> 
> echo 'void f(void) { asm("mov r7, #0" ::: "r7"); }' | arm-linux-gnueabi-gcc
> -march=armv7-a -O2  -mthumb -pg -S -xc -
> 
> silently accepts an inline asm statement that clobbers the frame pointer,
> but gcc rejects the same code if any of '-O0', '-fomit-frame-pointer' or
> 'fno-omit-frame-pointer' are used:
> 
> <stdin>: In function 'f':
> <stdin>:1:44: error: r7 cannot be used in 'asm' here
> 
> If using r7 in this case is indeed invalid, we need to ensure the kernel
> does not do this, and having gcc reject it would be helpful.

GCC will reject it if you explicitly enable the frame pointer. The logic seems wrong in that it doesn't report an error if the frame pointer is implicitly enabled via -pg. As a workaround for the kernel, just use -pg and -fno-omit-frame-pointer together.

Corrupting a frame pointer loses the ability to follow the frame chain, similar to a function built with -fomit-frame-pointer which will use r7 as a general purpose register.

However this always reports an error since this corruption of the frame pointer will cause a crash:

int *f(int x) { asm("mov r7, #0" ::: "r7"); return __builtin_alloca (x); }
Comment 2 nsz 2020-06-03 16:49:03 UTC
on arm the -pg abi is

func:
  push {lr}
  bl _gnu_mcount_nc
  ...

so no frame pointer is involved, -pg implying
-fno-omit-frame-pointer is a historical mistake i think
(because some targets required fp for -pg, but most don't).

ideally r7 clobber would just work with -pg -fomit-frame-pointer.
the alloca problem is a separate issue (that r7 clobber may not
work with alloca).
Comment 3 Wilco 2020-06-03 17:00:36 UTC
(In reply to nsz from comment #2)
> on arm the -pg abi is
> 
> func:
>   push {lr}
>   bl _gnu_mcount_nc
>   ...
> 
> so no frame pointer is involved, -pg implying
> -fno-omit-frame-pointer is a historical mistake i think
> (because some targets required fp for -pg, but most don't).

Right, so the claim that -pg implies -fno-omit-frame-pointer is wrong, and that means there is no bug in GCC. Looking at the latest docs, there is no mention of frame pointer for the -pg option, and neither does -fomit-frame-pointer discuss -pg. So this dependency must have been removed some time ago.

> ideally r7 clobber would just work with -pg -fomit-frame-pointer.
> the alloca problem is a separate issue (that r7 clobber may not
> work with alloca).

GCC correctly reports the error for that. So this can be closed then.
Comment 4 Nick Desaulniers 2020-06-03 17:16:04 UTC
(In reply to nsz from comment #2)
> on arm the -pg abi is
> 
> func:
>   push {lr}
>   bl _gnu_mcount_nc
>   ...
> 
> so no frame pointer is involved, -pg implying
> -fno-omit-frame-pointer is a historical mistake i think
> (because some targets required fp for -pg, but most don't).
> 
> ideally r7 clobber would just work with -pg -fomit-frame-pointer.
> the alloca problem is a separate issue (that r7 clobber may not
> work with alloca).

Should GCC change this for aaarch32 then (rather than closing the bug)?
Comment 5 nsz 2020-06-03 17:23:33 UTC
(In reply to Nick Desaulniers from comment #4)
> (In reply to nsz from comment #2)
> > ideally r7 clobber would just work with -pg -fomit-frame-pointer.
> > the alloca problem is a separate issue (that r7 clobber may not
> > work with alloca).
> 
> Should GCC change this for aaarch32 then (rather than closing the bug)?

yes, but that's bug 69690.