[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #3 from Jan Beulich --- (In reply to H.J. Lu from comment #0) > [hjl@gnu-cfl-2 gcc]$ cat x.s > movdir64b (%rdx), %rax > movdir64b (%edx), %eax > movdir64b foo(%rip), %rax > movdir64b foo(%eip), %eax > movdir64b foo(%rip), %eax > [hjl@gnu-cfl-2 gcc]$ gcc -c x.s > x.s: Assembler messages: > x.s:5: Error: invalid register operand size for `movdir64b' Which is intended, expected, and correct behavior. > [hjl@gnu-cfl-2 gcc]$ > > movdir64b foo(%rip), %eax > > should be treated as > > movdir64b foo(%eip), %eax We should not silently change what the programmer has (mistakenly) written, as it's ambiguous what would be meant: Could be they meant 32-bit addressing, but could also be they means 64-bit one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 H.J. Lu changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97257 --- Comment #4 from H.J. Lu --- (In reply to Jan Beulich from comment #3) > (In reply to H.J. Lu from comment #0) > > [hjl@gnu-cfl-2 gcc]$ cat x.s > > movdir64b (%rdx), %rax > > movdir64b (%edx), %eax > > movdir64b foo(%rip), %rax > > movdir64b foo(%eip), %eax > > movdir64b foo(%rip), %eax > > [hjl@gnu-cfl-2 gcc]$ gcc -c x.s > > x.s: Assembler messages: > > x.s:5: Error: invalid register operand size for `movdir64b' > > Which is intended, expected, and correct behavior. > > > [hjl@gnu-cfl-2 gcc]$ > > > > movdir64b foo(%rip), %eax > > > > should be treated as > > > > movdir64b foo(%eip), %eax > > We should not silently change what the programmer has (mistakenly) written, > as it's ambiguous what would be meant: Could be they meant 32-bit > addressing, but could also be they means 64-bit one. This specific case came from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97257 The address prefix changes the register operand in these instructions. (%rip) is a special case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #5 from Jan Beulich --- (In reply to H.J. Lu from comment #4) > This specific case came from > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97257 > > The address prefix changes the register operand in these instructions. > (%rip) is a special case. Which address prefix? There's not enough data in that bug for me to understand. But in any event, it's gcc producing wrong code then, and hence the issue should be fixed there, rather than silently "correcting" ambiguous code in gas. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #6 from H.J. Lu ---
(In reply to Jan Beulich from comment #5)
> (In reply to H.J. Lu from comment #4)
> > This specific case came from
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97257
> >
> > The address prefix changes the register operand in these instructions.
> > (%rip) is a special case.
>
> Which address prefix? There's not enough data in that bug for me to
> understand. But in any event, it's gcc producing wrong code then, and hence
> the issue should be fixed there, rather than silently "correcting" ambiguous
> code in gas.
In these instructions, the 0x67 prefix applies to the address prefix.
The address prefix should be extracted from the register operand, similar
to
if (i.tm.operand_types[0].bitfield.instance == Accum
|| i.operands == 1)
{
/* The address size override prefix changes the size of the
first operand. */
if (flag_code == CODE_64BIT
&& i.op[0].regs->reg_type.bitfield.word)
{
as_bad (_("16-bit addressing unavailable for `%s'"),
i.tm.name);
return 0;
}
if ((flag_code == CODE_32BIT
? i.op[0].regs->reg_type.bitfield.word
: i.op[0].regs->reg_type.bitfield.dword)
&& !add_prefix (ADDR_PREFIX_OPCODE))
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #7 from Jan Beulich --- Of course, that's all fine. But it's still gcc emitting wrong code, which gas legitimately diagnoses. You've introduced a bug into gas instead of fixing one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #8 from H.J. Lu --- (In reply to Jan Beulich from comment #7) > Of course, that's all fine. But it's still gcc emitting wrong code, which > gas legitimately diagnoses. You've introduced a bug into gas instead of > fixing one. No. The fix is also incomplete: [hjl@gnu-cfl-2 pr26685]$ cat foo.s movdir64b foo, %eax movdir64b 0x12345678, %eax [hjl@gnu-cfl-2 pr26685]$ make foo.o ./as -o foo.o foo.s foo.s: Assembler messages: foo.s:1: Error: invalid register operand size for `movdir64b' foo.s:2: Error: invalid register operand size for `movdir64b' make: *** [: foo.o] Error 1 [hjl@gnu-cfl-2 pr26685]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #9 from Jan Beulich --- (In reply to H.J. Lu from comment #8) > (In reply to Jan Beulich from comment #7) > > Of course, that's all fine. But it's still gcc emitting wrong code, which > > gas legitimately diagnoses. You've introduced a bug into gas instead of > > fixing one. > > No. How "no"? Just because the compiler produces bad code doesn't mean gas needs to correct it. Identical hand-written code like this absolutely needs to be diagnosed. As since there's no way to tell hand written code from compiler generated one, the fix will need to be in the compiler (otherwise I might accept us adjusting things for the compiler's sake). > The fix is also incomplete: > > [hjl@gnu-cfl-2 pr26685]$ cat foo.s > movdir64b foo, %eax > movdir64b 0x12345678, %eax > [hjl@gnu-cfl-2 pr26685]$ make foo.o > ./as -o foo.o foo.s > foo.s: Assembler messages: > foo.s:1: Error: invalid register operand size for `movdir64b' > foo.s:2: Error: invalid register operand size for `movdir64b' > make: *** [: foo.o] Error 1 > [hjl@gnu-cfl-2 pr26685]$ This is a different problem, and indeed wants fixing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685
--- Comment #10 from H.J. Lu ---
(In reply to Jan Beulich from comment #9)
> (In reply to H.J. Lu from comment #8)
> > (In reply to Jan Beulich from comment #7)
> > > Of course, that's all fine. But it's still gcc emitting wrong code, which
> > > gas legitimately diagnoses. You've introduced a bug into gas instead of
> > > fixing one.
> >
> > No.
>
> How "no"? Just because the compiler produces bad code doesn't mean gas needs
> to correct it. Identical hand-written code like this absolutely needs to be
> diagnosed. As since there's no way to tell hand written code from compiler
> generated one, the fix will need to be in the compiler (otherwise I might
> accept us adjusting things for the compiler's sake).
>
symbol(%rip) is similar to symbol and DISP. There is no real register
in memory operand. I am testing
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 094f555ea01..8f798479baa 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -7179,15 +7179,19 @@ process_suffix (void)
enum { need_word, need_dword, need_qword } need;
/* Check the register operand for the address size prefix if
- the memory operand is symbol(%rip). */
+ the memory operand has no real registers, like symbol, DISP
+ or symbol(%rip). */
if (i.mem_operands == 1
&& i.reg_operands == 1
&& i.operands == 2
-&& i.base_reg
-&& i.base_reg->reg_num == RegIP
-&& i.base_reg->reg_type.bitfield.qword
&& i.types[1].bitfield.class == Reg
-&& i.op[1].regs->reg_type.bitfield.dword
+&& (flag_code == CODE_32BIT
+ ? i.op[1].regs->reg_type.bitfield.word
+ : i.op[1].regs->reg_type.bitfield.dword)
+&& ((i.base_reg == NULL && i.index_reg == NULL)
+ || (i.base_reg
+ && i.base_reg->reg_num == RegIP
+ && i.base_reg->reg_type.bitfield.qword))
&& !add_prefix (ADDR_PREFIX_OPCODE))
return 0;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #11 from Jan Beulich --- (In reply to H.J. Lu from comment #10) > symbol(%rip) is similar to symbol and DISP. There is no real register > in memory operand. I disagree - the compiler ought to emit movdir64b foo(%eip), %eax or movdir64b foo(%rip), %rax in this case, whatever fits the x32 model better. The compiler ought to in particular be aware that the register operand of this insn is address-size-prefix, not operand-size-/REX-prefix controlled. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #12 from H.J. Lu --- (In reply to Jan Beulich from comment #11) > (In reply to H.J. Lu from comment #10) > > symbol(%rip) is similar to symbol and DISP. There is no real register > > in memory operand. > > I disagree - the compiler ought to emit > > movdir64b foo(%eip), %eax > > or > > movdir64b foo(%rip), %rax This is wrong for x32. > in this case, whatever fits the x32 model better. The compiler ought to in > particular be aware that the register operand of this insn is > address-size-prefix, not operand-size-/REX-prefix controlled. There is no RIP register in GCC. It isn't a real register. GCC always generate foo(%rip). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #13 from Jan Beulich --- (In reply to H.J. Lu from comment #12) > (In reply to Jan Beulich from comment #11) > > (In reply to H.J. Lu from comment #10) > > > symbol(%rip) is similar to symbol and DISP. There is no real register > > > in memory operand. > > > > I disagree - the compiler ought to emit > > > > movdir64b foo(%eip), %eax > > > > or > > > > movdir64b foo(%rip), %rax > > This is wrong for x32. You mean both, or (I assume) just the latter? > > in this case, whatever fits the x32 model better. The compiler ought to in > > particular be aware that the register operand of this insn is > > address-size-prefix, not operand-size-/REX-prefix controlled. > > There is no RIP register in GCC. It isn't a real register. GCC always > generate foo(%rip). That's not interesting, it's a gcc internal thing how to arrange for correct code to be generated. At the insn template level it's only % anyway. What is needed is some sort of flag to indicate that in this specific case it needs to be foo(%eip). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #14 from H.J. Lu --- (In reply to Jan Beulich from comment #13) > (In reply to H.J. Lu from comment #12) > > (In reply to Jan Beulich from comment #11) > > > (In reply to H.J. Lu from comment #10) > > > > symbol(%rip) is similar to symbol and DISP. There is no real register > > > > in memory operand. > > > > > > I disagree - the compiler ought to emit > > > > > > movdir64b foo(%eip), %eax This isn't necessary for x32. > > > > > > or > > > > > > movdir64b foo(%rip), %rax > > > > This is wrong for x32. > > You mean both, or (I assume) just the latter? > > > > in this case, whatever fits the x32 model better. The compiler ought to in > > > particular be aware that the register operand of this insn is > > > address-size-prefix, not operand-size-/REX-prefix controlled. > > > > There is no RIP register in GCC. It isn't a real register. GCC always > > generate foo(%rip). > > That's not interesting, it's a gcc internal thing how to arrange for correct > code to be generated. At the insn template level it's only % anyway. > What is needed is some sort of flag to indicate that in this specific case > it needs to be foo(%eip). No, we don't want 0x67 prefix for RIP-relative addressing for x32. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #15 from Jan Beulich --- (In reply to H.J. Lu from comment #14) > (In reply to Jan Beulich from comment #13) > > What is needed is some sort of flag to indicate that in this specific case > > it needs to be foo(%eip). > > No, we don't want 0x67 prefix for RIP-relative addressing for x32. You did read me writing "in this specific case", didn't you? I understand you don't want this in the general case. The way your (broken) change was written, you very much get a 0x67 prefix in this specific case, so I don't understand at all what you're trying to tell me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26692] New: [Z80][PATCH] Small GAS code improvements
https://sourceware.org/bugzilla/show_bug.cgi?id=26692 Bug ID: 26692 Summary: [Z80][PATCH] Small GAS code improvements Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sergey.belyashov at gmail dot com Target Milestone: --- Created attachment 12880 --> https://sourceware.org/bugzilla/attachment.cgi?id=12880&action=edit Small code improvements Add explicit initialization of expression structures. Improve hash sign handling when SDCC compatibility mode enabled. Improve indirect addressing detection -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26685] Error: invalid register operand size for `movdir64b'
https://sourceware.org/bugzilla/show_bug.cgi?id=26685 --- Comment #16 from H.J. Lu --- (In reply to Jan Beulich from comment #15) > (In reply to H.J. Lu from comment #14) > > (In reply to Jan Beulich from comment #13) > > > What is needed is some sort of flag to indicate that in this specific case > > > it needs to be foo(%eip). > > > > No, we don't want 0x67 prefix for RIP-relative addressing for x32. > > You did read me writing "in this specific case", didn't you? I understand > you don't want this in the general case. The way your (broken) change was > written, you very much get a 0x67 prefix in this specific case, so I don't > understand at all what you're trying to tell me. GNU assembler serves GCC. GCC doesn't use (%eip) and GCC always uses (%rip) for RIP-relative addressing. Assembler should extract the address size prefix from the register operand here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26694] New: gas x86-32: "can't handle non absolute segment in `lcall'" (or `ljmp')
https://sourceware.org/bugzilla/show_bug.cgi?id=26694 Bug ID: 26694 Summary: gas x86-32: "can't handle non absolute segment in `lcall'" (or `ljmp') Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: u1049321969 at caramail dot com Target Milestone: --- Binutils's x86 assembler (as of commit c81946efc22dbbe97ef8c934a5367e37bf101c48) does not allow me to use an unresolved or non-absolute symbol as the segment operand of an immediate far jump (`ljmp SEG, OFF') or far call (`lcall SEG, OFF'). I find this a rather strange restriction. == $ cd .../binutils-gdb $ cat >test5.s .code16 lcall $foo_seg, $foo_off $ git log -1 | head -6 commit c81946efc22dbbe97ef8c934a5367e37bf101c48 Author: Alex Coplan Date: Wed Sep 30 12:15:18 2020 +0100 NEWS: Mention recent Arm CPU support $ gas/as-new --32 test5.s test5.s: Assembler messages: test5.s:2: Error: can't handle non absolute segment in `lcall' == -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26694] gas x86-32: "can't handle non absolute segment in `lcall'" (or `ljmp')
https://sourceware.org/bugzilla/show_bug.cgi?id=26694 TK Chia changed: What|Removed |Added CC||u1049321969 at caramail dot com --- Comment #1 from TK Chia --- Created attachment 12881 --> https://sourceware.org/bugzilla/attachment.cgi?id=12881&action=edit Proposed patch I have enclosed a proposed patch --- including test case changes, and possible gas/ChangeLog entry. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26698] New: out of bounds access in mc_unify_path
https://sourceware.org/bugzilla/show_bug.cgi?id=26698
Bug ID: 26698
Summary: out of bounds access in mc_unify_path
Product: binutils
Version: 2.36 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: msebor at gmail dot com
Target Milestone: ---
Compiling binutils/windmc.c with the top of trunk of GCC 11 on x86_64 triggers
the following warning:
src/binutils-gdb/binutils/windmc.c:927:10: warning: array subscript -1 is
outside array bounds of ‘char[9223372036854775807]’ [-Warray-bounds]
927 | if (hsz[-1] != '/' && hsz[-1] != '\\')
| ~~~^~~~
/src/binutils-gdb/binutils/windmc.c:924:9: note: referencing an object of size
between 2 and 9223372036854775807 allocated by ‘xmalloc’
924 | hsz = xmalloc (strlen (path) + 2);
| ^~~
The warning looks valid to me. The function sets hsz to the result of
xmalloc() and then accesses hsz[-1] which is clearly before the beginning of
the allocated block:
atic const char *
mc_unify_path (const char *path)
{
char *end;
char *hsz;
if (! path || *path == 0)
return "./";
hsz = xmalloc (strlen (path) + 2);
strcpy (hsz, path);
end = hsz + strlen (hsz);
if (hsz[-1] != '/' && hsz[-1] != '\\')
strcpy (end, "/");
while ((end = strchr (hsz, '\\')) != NULL)
*end = '/';
return hsz;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26699] New: Failure to assemble aarch64 "isb sy" in LP64 Big Endian host environment
https://sourceware.org/bugzilla/show_bug.cgi?id=26699
Bug ID: 26699
Summary: Failure to assemble aarch64 "isb sy" in LP64 Big
Endian host environment
Product: binutils
Version: 2.36 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: ryo at nerv dot org
Target Milestone: ---
Created attachment 12884
--> https://sourceware.org/bugzilla/attachment.cgi?id=12884&action=edit
use same type of the aarch64_name_value_pair
In parse_barrier() of gas/config/tc-aarch64.c,
The return value of hash_find_n() is casted to "const asm_barrier_opt *o"
to access it, but struct aarch64_name_value_pair, which is the entity
returned by hash_find_n(), and asm_barrier_opt, which is not the same
in LP64 *BIG ENDIAN*, cannot be accessed correctly because the structure
of struct aarch64_name_value_pair and asm_barrier_opt are different.
Currently, the value of asm_barrier_opt is unsigned long, but it should be
uint32 (or aarch64_insn) the same as the value of aarch64_name_value_pair.
I've tested this in the netbsd/aarch64_be environment.
The same thing should happen in an LP64EB environment. (e.g. sparc64)
# uname -ap
NetBSD rockpro64 9.99.73 NetBSD 9.99.73 (GENERIC64EB) #225: Thu Oct 1
16:24:38 JST 2020 ryo@subq:/usr/src/sys/arch/evbarm/compile/GENERIC64EB evbarm
aarch64eb
# echo 'isb sy' | as
{standard input}: Assembler messages:
{standard input}:1: Error: the specified option is not accepted in ISB at
operand 1 -- `isb sy'
--
You are receiving this mail because:
You are on the CC list for the bug.
