[Bug gas/30120] x87: fucomp assembled as fucom

2023-02-13 Thread matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30120

--- Comment #5 from Michael Matz  ---
(In reply to Michael Matz from comment #4)
> commit 25a0d393c72 (with a little addition to a testcase to check for at
> least this problem)

FWIW, I've also checked all patterns touched by the initial patch now and also
don't see a further problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/30120] x87: fucomp assembled as fucom

2023-02-13 Thread matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30120

Michael Matz  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Michael Matz  ---
commit 25a0d393c72 (with a little addition to a testcase to check for at least
this problem)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/30120] x87: fucomp assembled as fucom

2023-02-13 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30120

Jan Beulich  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Jan Beulich  ---
(In reply to Michael Matz from comment #2)
> Came in with bd7828084 "x86: use ModR/M for FPU insns with operands".
> 
> The proper Reg field of ModRM for the popping variant of fucom is '5' not
> '4'.
> So this:
> 
> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -651,7 +651,7 @@ fcompp, 0xded9, FP, NoSuf, {}
>  fucom, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
>  // alias for fucom %st(1)
>  fucom, 0xdde1, i387, NoSuf, {}
> -fucomp, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
> +fucomp, 0xdd/5, i387, Modrm|NoSuf, { FloatReg }
>  // alias for fucomp %st(1)
>  fucomp, 0xdde9, i387, NoSuf, {}
>  fucompp, 0xdae9, i387, NoSuf, {}

Would you mind simply committing your change?

> (didn't check the other insns touched by the patch)

I've just gone through using a pattern I didn't use when composing the change,
and I didn't find any other similar issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/30120] x87: fucomp assembled as fucom

2023-02-13 Thread matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30120

Michael Matz  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |jbeulich at suse dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/30120] x87: fucomp assembled as fucom

2023-02-13 Thread matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30120

--- Comment #2 from Michael Matz  ---
Came in with bd7828084 "x86: use ModR/M for FPU insns with operands".

The proper Reg field of ModRM for the popping variant of fucom is '5' not '4'.
So this:

--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -651,7 +651,7 @@ fcompp, 0xded9, FP, NoSuf, {}
 fucom, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
 // alias for fucom %st(1)
 fucom, 0xdde1, i387, NoSuf, {}
-fucomp, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
+fucomp, 0xdd/5, i387, Modrm|NoSuf, { FloatReg }
 // alias for fucomp %st(1)
 fucomp, 0xdde9, i387, NoSuf, {}
 fucompp, 0xdae9, i387, NoSuf, {}

(didn't check the other insns touched by the patch)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/30120] x87: fucomp assembled as fucom

2023-02-13 Thread matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30120

--- Comment #1 from Michael Matz  ---
The problem exists in current master.  2.39 and 2.40 seem to be okay.

-- 
You are receiving this mail because:
You are on the CC list for the bug.