https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124336
Bug ID: 124336
Summary: different (noop) memory access size generated for
-masm=intel/att with -fstack-check
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 63806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63806&action=edit
reduced testcase
I am not entirely sure if this is a bug, but it's mixing access sizes on stack,
which might have negative performance impact.
$ x86_64-pc-linux-gnu-gcc -fstack-check testcase.c -c && objdump -S testcase.o
> att.S
$ x86_64-pc-linux-gnu-gcc -fstack-check testcase.c -c -masm=intel && objdump -S
testcase.o > intel.S
$ diff -u att.S intel.S
--- att.S 2026-03-02 20:17:26.613319437 +0100
+++ intel.S 2026-03-02 20:17:46.803347637 +0100
@@ -10,50 +10,50 @@
4: 4c 8d 9c 24 00 c0 ff lea -0x4000(%rsp),%r11
b: ff
c: 48 81 ec 00 10 00 00 sub $0x1000,%rsp
- 13: 48 83 0c 24 00 orq $0x0,(%rsp)
- 18: 4c 39 dc cmp %r11,%rsp
- 1b: 75 ef jne c <foo+0xc>
- 1d: 48 81 ec 88 0e 00 00 sub $0xe88,%rsp
- 24: 48 83 0c 24 00 orq $0x0,(%rsp)
...
+ 13: 83 0c 24 00 orl $0x0,(%rsp)
+ 17: 4c 39 dc cmp %r11,%rsp
+ 1a: 75 f0 jne c <foo+0xc>
+ 1c: 48 81 ec 88 0e 00 00 sub $0xe88,%rsp
+ 23: 48 83 0c 24 00 orq $0x0,(%rsp)
...
The first orq/orl is using different operand size.
I observe a similar behavior with -fstack-clash-protection
Is -masm=att/intel supposed to generate the same object code?
