x86: improve handling of insns with ambiguous operand sizes

Commit b76bc5d54e ("x86: don't default variable shift count insns to
8-bit operand size") pointed out a very bad case, but the underlying
problem is, as mentioned on various occasions, much larger: Silently
selecting a (nowhere documented afaict) certain default operand size
when there's no "sizing" suffix and no suitable register operand(s) is
simply dangerous (for the programmer to make mistakes).

While in Intel syntax mode such mistakes already lead to an error (which
is going to remain that way), AT&T syntax mode now gains warnings in
such cases by default, which can be suppressed or promoted to an error
if so desired by the programmer. Furthermore at least general purpose
insns now consistently have a default applied (alongside the warning
emission), rather than accepting some and refusing others.

No warnings are (as before) to be generated for "DefaultSize" insns as
well as ones acting on selector and other fixed-width values. For
SYSRET, however, the DefaultSize needs to be dropped - it had been
wrongly put there in the first place, as it's unrelated to .code16gcc
(no stack accesses involved).

As set forth as a prereq when I first mentioned this intended change a
few years back, Linux as well as gcc have meanwhile been patched to
avoid (emission of) ambiguous operands (and hence triggering of the new
warning).

Note that I think that in 64-bit mode IRET and far RET would better get
a diagnostic too, as it's reasonably likely that a suffix-less instance
really is meant to be a 64-bit one. But I guess I better make this a
separate follow-on patch.

Note further that floating point operations with integer operands are an
exception for now: They continue to use short (16-bit) operands by
default even in 32- and 64-bit modes.

Finally note that while {,V}PCMPESTR{I,M} would, strictly speaking, also
need to be diagnosed, with their 64-bit forms not being very useful I
think it is better to continue to avoid warning about them (by way of
them carrying IgnoreSize attributes).

1 files changed, 25 insertions, 0 deletions

diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index e8685dd..6d556a0 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -723,6 +723,31 @@ assembler which assumes that a missing mnemonic suffix implies long
 operand size.  (This incompatibility does not affect compiler output
 since compilers always explicitly specify the mnemonic suffix.)
 
+When there is no sizing suffix and no (suitable) register operands to
+deduce the size of memory operands, with a few exceptions and where long
+operand size is possible in the first place, operand size will default
+to long in 32- and 64-bit modes.  Similarly it will default to short in
+16-bit mode. Noteworthy exceptions are
+
+@itemize @bullet
+@item
+Instructions with an implicit on-stack operand as well as branches,
+which default to quad in 64-bit mode.
+
+@item
+Sign- and zero-extending moves, which default to byte size source
+operands.
+
+@item
+Floating point insns with integer operands, which default to short (for
+perhaps historical reasons).
+
+@item
+CRC32 with a 64-bit destination, which defaults to a quad source
+operand.
+
+@end itemize
+
 Almost all instructions have the same names in AT&T and Intel format.
 There are a few exceptions.  The sign extend and zero extend
 instructions need two sizes to specify them.  They need a size to