Re: PATCH: PR gas/5534: "XXX PTR" isn't checked properlyinIntelsyntax

["H.J. Lu" <hjl at lucon dot org>]

On Mon, Jan 14, 2008 at 02:17:05PM +0000, Jan Beulich wrote:
> >>> "H.J. Lu" <hjl@lucon.org> 14.01.08 14:55 >>>
> >On Mon, Jan 14, 2008 at 08:59:29AM +0000, Jan Beulich wrote:
> >> >Unspecified means size can be unspecified. AnySize means any size
> >> >is ok.
> >> 
> >> But you continue to have Unspecified in places where a size specification
> >> is a requirement (at least in Intel syntax; I never got any clarification on
> >> whether AT&T syntax silently enforcing a certain size if none was
> >> specified is really intended behavior).
> >> 
> >
> >As you mentioned above, since for some instructions, the old assembler
> >selected a default size even in Intel mode when size isn't provided, I
> 
> I don't think I said anything like that. Quite a while back, I made ambiguous
> operand sizes an error in Intel mode, and I'm not aware that I missed any
> cases.

There are 2 cases when Unspecified is used with more than one sizes:

1. Only one size is allowed given the second operand, like

movw (%eax), %ax
movl (%eax), %eax
mov ax, WORD PTR [ebx]
mov eax, DWORD PTR [ebx]

2. 64bit extension adds a new size and we don't want to disallow the 32bit
default version:

bash-3.2$ cat x.s
        .intel_syntax noprefix
cvtsi2sd xmm1, [rax]
cvtsi2sd xmm1,DWORD PTR [rax]
cvtsi2sd xmm1,QWORD PTR [rax]
bash-3.2$ /usr/bin/as -o x.o x.s
bash-3.2$ objdump -dw x.o

x.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   f2 0f 2a 08             cvtsi2sdl (%rax),%xmm1
   4:   f2 0f 2a 08             cvtsi2sdl (%rax),%xmm1
   8:   f2 48 0f 2a 08          cvtsi2sdq (%rax),%xmm1
bash-3.2$ 

If you can find a case where Unspecified is used with more than 1 sizes
in a different way, please let me know.

> 
> >used Unspecified on them. Otherwise, the new assembler will be
> >incompatible with the old one. I will enforce the operand size on
> 
> I think it should (in AT&T mode) at least warn in that case (providing the
> option to make this an error in a couple years time); I'm asking to make
> this an error unconditionally in Intel mode (as it's an error in MASM).
> 

I will generate an error in AT&T mode if there is no such an instruction.
I disallowed "fnstsw %eax".  I don't want to issue an warning for
default size in AT&T mode since it is well understood and may generate 
too many warnings.


H.J.