Regression: operand size mismatch for `push'

[Andrew Cooper]

Hello,

I think this is related to
https://sourceware.org/bugzilla/show_bug.cgi?id=30928 but I can't bisect
myself.  It did regress between 2.39 and 2.41

$ /local/bin/bin-2.39/bin/as push.S -o push.o
$ /local/bin/bin-2.41/bin/as push.S -o push.o
push.S: Assembler messages:
push.S:5: Error: operand size mismatch for `push'

$ cat push.S
        .text
        .code64
code64:
        push $0
        push $1f
1:

        .code32
code32:
        push $0
        push $1f
1:


Using `push` without an explicit suffix is important for writing
bitness-agnostic assembly.  Right now, 2.41's complains are asymmetric,
insisting on a q suffix in 64bit code while not insisting on an l suffix
in 32bit code.

For stack operations, there is always a default operand size (from the
operating mode), which is always the one the programmer wants, given no
indication to the contrary.

The push $imm forms are a little weird.  Stack operations in x86 have an
operand size from 16, 32 or 64 (with 64 and 32 un-encodable in each
others mode).

The 6a (push $imm8) and 68 (push $imm) encodings look like a
byte/non-byte pair, but do not follow the normal operand size rules.  As
such, the use of the wlq suffixes go wrong.

The only way of encoding the $imm16 form is via the 66 prefix or w
suffix, which changes the operand size to 16 and also misaligns the
stack pointer.  The l or q suffixes (which result in no prefix) retain
the default operand size, and apply equally to the byte and non-byte forms.

Despite experimenting, I can't find a way of spelling `push $0` that
results in the 68 00 00 00 00 form.  push.d32 does silence the suffix
warning, but neither .d32 nor .d8 force the 1 or 4 byte immediate
forms.  The form chosen is always based on range, unless there's a
relocation in which case the $imm32 form is used.


This is clearly a tangled part of parsing, but insisting on a q suffix
when the operand size is unambiguous does adversely impact existing
code, and the fact that an l suffix is not insisted upon suggests that
this was an oversight rather than an intentional change in behaviour.

Thanks,

~Andrew