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

[H.J. Lu]

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.

-- 
H.J.