[PATCH v3 03/10] x86: move certain MOVSX/MOVZX tests

[H.J. Lu]

On Wed, Jan 22, 2020 at 8:28 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 22.01.2020 17:09, H.J. Lu wrote:
> > On Wed, Jan 22, 2020 at 8:04 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 20.01.2020 16:33, H.J. Lu wrote:
> >>> On Mon, Jan 20, 2020 at 7:30 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 13.01.2020 18:33,  H.J. Lu  wrote:
> >>>>> On Fri, Dec 27, 2019 at 1:24 AM Jan Beulich <JBeulich@suse.com> wrote:
> >>>>>>
> >>>>>> Some encodings are about to gain a warning - move them from test cases
> >>>>>> not expecting any diagnostics to the new, dedicated ones, to allow
> >>>>>> better focus on the actual changes in the subsequent patch.
> >>>>>>
> >>>>>> The new tests added have some wrong expectations right now, which will
> >>>>>> be corrected by the next patch. The test is being added here to make
> >>>>>> more visible which cases actually were wrong (and hence get changed),
> >>>>>> besides demonstrating that in the vast majority of cases the subsequent
> >>>>>> change doesn't alter generated code.
> >>>>>
> >>>>> We can't change the encoding nor disallow it.  At most, we can issue a
> >>>>> warning.   If it is the case, calling it "wrong" isn't accurate.
> >>>>
> >>>> If you look at the following patch you'll find that the two cases
> >>>> where an encoding actually changes, this will then be accompanied
> >>>
> >>> Please open a bug for wrong encoding before we decide what to do
> >>> about it.   At minimum, we need a record.
> >>
> >> Seeing you say "We should make them hard errors now." in that bug,
> >> I hope it is clear that that's an orthogonal job, which - once
> >> done - will convert what gets warned about in the next patch (i.e.
> >> the cases where you're worried about encoding changes) into errors
> >> at the same time. Hence I'd like to ask what the disposition of
> >> this and the next patch is: With your cited remark in the bug, I
> >> don't see what adjustments you want to see done here. IOW it would
> >> seem to me that both patches could go in as they are.
> >
> > All MOVZX with incorrect operands should be hard errors in
> > 16-bit, 32-bit and 64-bit modes.
>
> Only once other insns behave in a similar way. Programmers should
> be able to predict assembler behavior, and hence derive what'll
> happen for one insn/operands combination from what happens from
> any other, sufficiently similar one. This is what the patch helps
> with. The consistency in behavior won't be broken down the road
> when you or someone else switches the behavior you talk about
> from being warnings to being errors. But it can't be the purpose
> of this (or any) patch to introduce special cases for certain
> insns when none are warranted. In fact we should try to reduce
> the number of special cases (which I think I'm slowly making
> progress with, see e.g. the change to md_assemble() by patch 4,
> which, yes, unavoidably comes with the need to insert less
> arbitrary special casing code in process_suffix()).
>
> If you make the change you've outlined, I'll be happy to re-base
> the patches here on top, which will merely mean adjustments to
> the testsuite additions. If, however, said change will take time,
> then may I please get approval to get in the two patches here?
>

I am checking in this patch.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-Always-disallow-double-word-suffix-with-word-gen.patch
Type: text/x-patch
Size: 7154 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20200122/e1f9c50a/attachment.bin>