bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/29525] x86: CMPSD and MOVSD wrongly accepted in AT&T mode


From: jbeulich at suse dot com
Subject: [Bug gas/29525] x86: CMPSD and MOVSD wrongly accepted in AT&T mode
Date: Thu, 01 Dec 2022 08:19:07 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=29525

Jan Beulich <jbeulich at suse dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #2 from Jan Beulich <jbeulich at suse dot com> ---
Your response doesn't justify the "won't fix" at all. In fact we did discuss a
compromise on the mailing list, and that's what I think we should follow:

There are known uses of MOVSD (without operands) in otherwise AT&T code.
Clang's integrated assembler also accepts this as an exception. So we want top
keep that, but it looks more than reasonable to warn about such uses.

Despite e.g. Clang's integrated assembler _not_ accepting CMPSD, we may want to
retain support for its no-operands form as well (again with a warning).
Nevertheless that's inconsistent with the other string insns (where we don't
accept *SD), so doing so is strictly optional (and you saying "For other string
instructions" is simply not stating the truth).

There is no point in retaining _bogus_ support for the two-operand forms of
MOVSD / CMPSD.

As a general remark - please don't close bug reports lightly as "won't fix".
Doing so needs to be based on objective reasons, not personal taste. This
includes qualifying some issues as "minor" (and then using just that as a
justification). It may be acceptable to not invest time in fixing such, but if
a fix is available and isn't entirely unreasonable, it shouldn't be rejected.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]