Re: PATCH: PR gas/6518: wrong diagnostic for vcvtpd2dq/vcvtpd2ps/vcvttpd2dq

["Jan Beulich" <jbeulich at novell dot com>]

>>> "H.J. Lu" <hjl.tools@gmail.com> 23.05.08 15:54 >>>
>Intel syntax has operand size. I am checking in this patch to change
>error messsage when there is no match.
>
>
>H.J.
>----
>2008-05-23  H.J. Lu  <hongjiu.lu@intel.com>
>
>	PR gas/6518
>	* config/tc-i386.c (match_template): Report ambiguous operand
>	size, not invalid suffix when there is no match in Intel
>	syntax.
>
>--- gas/config/tc-i386.c.256	2008-05-02 10:08:48.000000000 -0700
>+++ gas/config/tc-i386.c	2008-05-23 06:46:27.000000000 -0700
>@@ -3754,8 +3754,12 @@ match_template (void)
>   if (t == current_templates->end)
>     {
>       /* We found no match.  */
>-      as_bad (_("suffix or operands invalid for `%s'"),
>-	      current_templates->start->name);
>+      if (intel_syntax)
>+	as_bad (_("ambiguous operand size or operands invalid for `%s'"),
>+		current_templates->start->name);
>+      else
>+	as_bad (_("suffix or operands invalid for `%s'"),
>+		current_templates->start->name);
>       return 0;
>     }

I disagree to this approach of fixing the issue - for one, the existing
diagnostic shouldn't become more vague for cases it was precise for
so far, and secondly in other cases operand size ambiguity is being
reported correctly:

	.intel_syntax noprefix
	.text
Start:
	vcvtpd2ps xmm0, [eax]
	vcvtpd2ps xmm0, xmmword ptr [eax]
	vcvtpd2ps xmm0, ymmword ptr [eax]

	movzx	eax, [eax]
	movzx	eax, byte ptr [eax]
	movzx	eax, word ptr [eax]

	add	[eax], 1
	add	byte ptr [eax], 1
	add	word ptr [eax], 1
	add	dword ptr [eax], 1

	mov	[eax], 1
	mov	byte ptr [eax], 1
	mov	word ptr [eax], 1
	mov	dword ptr [eax], 1

You'll note that for movzx the same problem as for the three newly
added AVX instructions exists, so this (and then obviously movsx) is
another candidate needing proper fixing - it properly showed the
"ambiguous operand size" message in 2.18, so I'm afraid this is
another regression introduced by some of the large re-work you did
(the code is still there, at around tc-i386.c:2700, but presumably
isn't being reached anymore).

Jan