[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 Jan Beulich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jan Beulich --- Sorted on master and 2.41. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #10 from cvs-commit at gcc dot gnu.org ---
The binutils-2_41-branch branch has been updated by Jan Beulich
:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7fe76f02413fff61566ae52ec80d581da1e264a2
commit 7fe76f02413fff61566ae52ec80d581da1e264a2
Author: Jan Beulich
Date: Wed Sep 27 10:53:38 2023 +0200
x86-64: fix suffix-less PUSH of symbol address
PR gas/30856
In 5cc007751cdb ("x86: further adjust extend-to-32bit-address
conditions") I neglected the case of PUSH, which is the only insn
allowing (proper) symbol addresses to be used as immediates (not
displacements, like CALL/JMP) in the absence of any register operands.
Since it defaults to 64-bit operand size, guessing an L suffix is wrong
there.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #9 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Jan Beulich :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fb1c10585ead9acc8d9f9d24ab093cbe5e962257
commit fb1c10585ead9acc8d9f9d24ab093cbe5e962257
Author: Jan Beulich
Date: Wed Sep 27 10:53:38 2023 +0200
x86-64: fix suffix-less PUSH of symbol address
PR gas/30856
In 5cc007751cdb ("x86: further adjust extend-to-32bit-address
conditions") I neglected the case of PUSH, which is the only insn
allowing (proper) symbol addresses to be used as immediates (not
displacements, like CALL/JMP) in the absence of any register operands.
Since it defaults to 64-bit operand size, guessing an L suffix is wrong
there.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #8 from Jan Beulich --- https://sourceware.org/pipermail/binutils/2023-September/129587.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #7 from Jan Beulich --- (In reply to Antoni Boucher from comment #6) > Do you mean that gcc produces invalid asm when using the Intel syntax and > should be using pushq? No. "push offset ..." is the correct form in Intel syntax. What I'm saying is that it is wrong to emit such code without -mcmodel=kernel, for there not being any guarantee that the resulting code will actually link. (At the same time an assembly programmer may write such code, knowing the target environment.) > I was under the impression that suffixes like q was ATT syntax, but I > couldn't find any reference of the intel syntax allowed in GNU as. It does > seem to allow pushq even for the Intel syntax, though. It does, but more by mistake than deliberately. > Other assemblers allow "push qword". That's a different form of push, with a memory operand (here we're talking about immediate / address operands). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #6 from Antoni Boucher --- (In reply to Jan Beulich from comment #5) > Well, only partly: PUSHQ works, but PUSH (no suffix) doesn't according to my > testing. Do you mean that gcc produces invalid asm when using the Intel syntax and should be using pushq? I was under the impression that suffixes like q was ATT syntax, but I couldn't find any reference of the intel syntax allowed in GNU as. It does seem to allow pushq even for the Intel syntax, though. Other assemblers allow "push qword". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #5 from Jan Beulich --- (In reply to Antoni Boucher from comment #4) > I attached the ATT version (produced by gcc) that still works. Well, only partly: PUSHQ works, but PUSH (no suffix) doesn't according to my testing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #4 from Antoni Boucher --- Created attachment 15119 --> https://sourceware.org/bugzilla/attachment.cgi?id=15119&action=edit Working example with ATT syntax Yes, this is useful for -mcmodel=kernel and the code continues to work when not using the Intel asm syntax, i.e. there's a difference in behavior with the ATT syntax. I attached the ATT version (produced by gcc) that still works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |jbeulich at suse dot com Last reconfirmed||2023-09-21 --- Comment #3 from Jan Beulich --- I'll look into why this happens, but: 1) I'm not sure we do ourselves (and our users) much good if we allow this again. The referenced symbol is severely constrained in where in the address space it may live. Nevertheless similar symbol uses (with e.g. MOV or ADD) still work, so it is likely necessary to fix this at least for consistency reasons, and for --x32. 2) I'm not convinced the compiler should actually emit such code. It can't know where the linker script (which may be a custom one) would put the executable. When put outside of the low 2G of address space and outside of the high 2G of address space, linking would fail from what I can tell. The emitted code looks to be legitimate only when -mcmodel=kernel is in effect, or in --x32 mode. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 --- Comment #2 from Antoni Boucher --- Created attachment 15113 --> https://sourceware.org/bugzilla/attachment.cgi?id=15113&action=edit ASM reproducer for the bug Here it is. You simply need to run GNU as on this file to trigger the error. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30856] Regression: operand size mismatch for `push'
https://sourceware.org/bugzilla/show_bug.cgi?id=30856 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Antoni Boucher from comment #0) Hi Antoni, > Reproducer for the bug Please could you upload the assembler output from the compiler ? It is likely that this bug is dependent upon the version of the compiler that is being used, so in order to reproduce and investigate the problem we really need the assembler output, rather than the C source file. It may also be that this problem is actually a bug in the compiler which was not being caught by the 2.40 assembler, but which is now detected by the 2.41 assembler. Hence having access to the assembler source file should allow us to find out if this is true. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
