[PATCH v3 03/10] x86: move certain MOVSX/MOVZX tests
H.J. Lu
hjl.tools@gmail.com
Wed Jan 22 12:20:00 GMT 2020
On Wed, Jan 22, 2020 at 3:03 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.
>
> While I still don't see the point, here you go: PR/25438.
>
> Jan
movzbw %al, %ecx
movzbw %al, %rcx
movzbl %al, %cx
movzbl %al, %rcx
movzbq %al, %cx
movzbq %al, %ecx
should be hard error. Clearly they are typos.
--
H.J.
More information about the Binutils
mailing list