[Bug inline-asm/97708] New: Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Bug ID: 97708
Summary: Inline asm does not use the local register asm
specified with register ... asm() as input
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: bp at alien8 dot de
Target Milestone: ---
Building the below on x86-64 with gcc9, gcc10 and Segher built with gcc11
20201015:
---
int main(void)
{
register float foo asm ("xmm0") = 0.99f;
asm volatile("movl %0, %%r8d\n\t"
"vmcall\n\t"
:: "g" (foo));
return 0;
}
---
results in gcc not using the xmm0 register directly as the input register to
the asm statement but does something funky:
1125 :
1125: 55 push %rbp
1126: 48 89 e5mov%rsp,%rbp
1129: f3 0f 10 05 d3 0e 00movss 0xed3(%rip),%xmm0# 2004
<_IO_stdin_used+0x4>
1130: 00
1131: 66 0f 7e c0 movd %xmm0,%eax
1135: 41 89 c0mov%eax,%r8d
1138: 0f 01 c1vmcall
by loading through the %eax GPR and producing wrong code without even a
warning. I'm not saying this example is supposed to make sense but this should
fail instead by trying to compile:
$ cat xmm1.s
movl %xmm0,%eax
$ x86_64-linux-as xmm1.s -o xmm1.o
xmm1.s: Assembler messages:
xmm1.s:1: Error: unsupported instruction `mov'
and fail the build because plain MOV cannot use an XMM reg as a source.
Thx.
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708 --- Comment #2 from Boris --- (In reply to Andrew Pinski from comment #1) > "g" constraint won't work here: So in that case gcc should fail the build. Which it does not.
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708 --- Comment #7 from Boris --- (In reply to Jakub Jelinek from comment #6) > I agree with Andrew here, the compiler does what it is asked to do, so puts > the value into either memory or general purpose register. Neither "r" nor > "g" allows putting the value into an SSE register. Use "x" constraint for > that. Look at the documentation: "‘g’ Any register, memory or immediate integer operand is allowed, except for registers that are not general registers." so this reads to me like "g" doesn't allow xmm registers. What gcc does is go "around the corner" and stick it in a g-allowed register. So that behavior should *at* *least* be documented so that people know what's going on here. Because it is confusing...
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708 --- Comment #11 from Boris --- Drop "general": "‘g’ Any register, memory or immediate integer operand is allowed." because, as you guys say, it would stick it anywhere.
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708 --- Comment #13 from Boris --- Then you'd need to add a sentence saying that the register asm() specification has lower prio and thus overridden by the input operand constraint. Which is what we have here. And then refer to the text Segher posted in comment #5 to state that it doesn't hold true in that case...
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708 --- Comment #16 from Boris --- (In reply to Jakub Jelinek from comment #14) > No, why? You ask it to go into a general register, so it goes there. The > local register variable has no priority at all. And where in the documentation does it say that it has no priority? Not here: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html AFAICT.
[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708 --- Comment #18 from Boris --- It would be awesome if this text continued: "... and specify any constraint letter that matches the register. If the operand constraint doesn't match the register, former has higher priority over the local register specification and gcc will adhere to the constraint specification." I'll even put it in a patch and send it on... :-)
[Bug other/106571] New: Implement -Wsection diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
Bug ID: 106571
Summary: Implement -Wsection diag
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bp at alien8 dot de
Target Milestone: ---
Hi,
clang has this -Wsection diag which does:
https://clang.llvm.org/docs/DiagnosticsReference.html#wsection
It would be good to have it in gcc too so that declarations like
extern u64 x86_spec_ctrl_current;
for variable definitions which belong to a specific section:
__attribute__((section(".data..percpu" ""))) __typeof__(u64)
x86_spec_ctrl_current;
get caught:
arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on
redeclared variable [-Werror,-Wsection]
Thx.
[Bug c/106571] Implement -Wsection diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571 --- Comment #2 from Boris --- How can you check a mismatch if only the definition has the section attribute? Here's the kernel commit which fixes this for clang: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=db886979683a8360ced9b24ab1125ad0c4d2cf76 there's the same example in the commit message.
[Bug c/106571] Implement -Wsection diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
--- Comment #5 from Boris ---
(In reply to Michael Matz from comment #4)
> Boris: what does DECLARE_PER_CPU() expand into? Are there other attributes
> that could be usefully checked for mismatch between decl and def?
Unfortunately,
DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
expands only to:
extern __attribute__((section(".data..percpu" ""))) __typeof__(u64)
x86_spec_ctrl_current;
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 Boris changed: What|Removed |Added CC||bp at alien8 dot de --- Comment #20 from Boris --- (In reply to prathamesh3492 from comment #14) > The patch enables warning with Wextra due to PR91593 and warnings with > allmodconfig kernel build. Once these issues are resolved, we could > consider promoting it to Wall. Yes, you should. I just built 6.4 allmodconfig and there are no warnings anymore likely because clang enables this warning by default and since we build the kernel with both compilers, people have fixed them all in the meantime. And clang did catch a legitimate error with this warning here while gcc didn't using the default warning flags but it warned with -Wextra. So I think we'll enable that warning by default in the kernel build and it does make sense to do that in gcc too, I'd say. Thx.
