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

H.J. Lu hjl.tools@gmail.com
Mon Jan 20 15:34:00 GMT 2020


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.

> by a warning. I don't see why disallowing an insn which we've
> mistakenly accepted so far wouldn't be permitted. How would we
> ever fix any bugs involving e.g. mis-parsing of operands, or
> wrongly coded insn templates. By there then being an error, it'll
> be quite clear what needs changing on the source side. I'm also
> pretty sure that such has happened quite a few times in the past.
>
> Jan



-- 
H.J.



More information about the Binutils mailing list