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.
(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); }
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).
(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.
(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)?
(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.