[PATCH 06/10] x86: improve handling of insns with ambiguous operand sizes

[Jan Beulich]

On 06.08.2019 22:26,  H.J. Lu  wrote:
> On Tue, Aug 6, 2019 at 7:27 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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).
> 
> If there may be an ambiguity, a size suffix can be used.  Assembler isn't
> responsible for programmer's errors.

But it should, as far as possible, aid him. Even more so when such
aid so far has been there in some cases, but not in others.

>> 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
> 
> This punishes the perfectly good assembly sources.

What is "perfectly good" here? The lack of a disambiguating suffix is
is definitely not "perfectly good".

Furthermore - if you really mean to object to warnings in such cases,
then you should have said so when I first announced the plan for this
change. All you demanded back then was that gcc and Linux be adjusted
up front to not trigger any such new warnings (and you had offered to
take care of glibc yourself).

>> 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. The set of
>> "DefaultSize" one gets slightly widened for the purposes here.
> 
> Widen the default size set avoids generate warnings.  It sounds to
> me these warnings isn't really necessary.

I'm afraid I don't understand this reply of yours. As per the original
discussion a few years back the warnings are to be introduced, and
hence they want to be suppressed in sufficiently unambiguous cases
(like the branches getting DefaultSize added here, or the MOVSX/MOVSX
insns with 16-bit destinations in the later patch).

Jan