This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/3] x86: extend LEA's segment override warning


On Thu, Feb 13, 2020 at 8:38 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.02.2020 17:31, H.J. Lu wrote:
> > On Thu, Feb 13, 2020 at 8:00 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 13.02.2020 16:51, H.J. Lu wrote:
> >>> On Thu, Feb 13, 2020 at 6:48 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 13.02.2020 15:11, H.J. Lu wrote:
> >>>>> On Thu, Feb 13, 2020 at 6:05 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> For one both possible forms should be warned about. And then there are
> >>>>>> a couple of MPX insns behaving LEA-like, which should be warned about in
> >>>>>> the same way. Finally, to guard against future surprises, qualify the
> >>>>>> original opcode check by excluding VEX/EVEX-like templates.
> >>>>>>
> >>>>>> gas/
> >>>>>> 2020-02-XX  Jan Beulich  <jbeulich@suse.com>
> >>>>>>
> >>>>>>         * config/tc-i386.c (process_operands): Also check insn prefix
> >>>>>>         for ineffectual segment override warning. Also cover BNDC* and
> >>>>>>         BNDMK there. Don't cover possible VEX/EVEX encoded insns there.
> >>>>>>         * testsuite/gas/i386/lea.s, testsuite/gas/i386/lea.d,
> >>>>>>         testsuite/gas/i386/lea.e: New.
> >>>>>>         * testsuite/gas/i386/i386.exp: Run new test.
> >>>>>>
> >>>>>
> >>>>> Why should it be warning, not error?
> >>>>
> >>>> Because the code isn't wrong, just inefficient. I also don't think
> >>>> converting from warning to error should be done in the same patch
> >>>> as extending the coverage of what gets a diagnostic emitted.
> >>>
> >>> What do we gain to allow it?
> >>
> >> It has always been allowed, and in one of the two cases even silently.
> >> We're liable to break people's working code if we changed this.
> >
> > Given that MPX has been deprecated, MPX codes are very unlikely to
> > change.  Assembler shouldn't bother with this.
>
> What a strange position to take. Anyway, are you saying the change is
> going to be okay if I remove the MPX aspects from it? (It is only
> this 3rd reply of yours where you mention MPX, so I'm a little
> puzzled.)
>

Yes.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]