On Sun, Jun 21, 2020 at 10:18 AM Uros Bizjak <ubiz...@gmail.com> wrote:
>
> On Sat, Jun 20, 2020 at 3:40 PM H.J. Lu <hjl.to...@gmail.com> wrote:
>
> > > > > >> 2) can we automatically deduce option name:
> > > > > >>
> > > > > >>> + ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO,
> > > > > >>> "-mrdpid")
> > > > > >>> + ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO,
> > > > > >>> "-mrdrnd")
> > > > > >>
> > > > > >> I mean "-m" + "rdrnd" == "-mrdrnd" ?
> > > > > >
> > > > > > The new option field serves 2 purposes:
> > > > > >
> > > > > > 1. Not all features have a corresponding command-line option
> > > > > >
> > > > > > ISA_NAMES_TABLE_ENTRY("cmov", FEATURE_CMOV, P_ZERO, NULL)
> > > > > >
> > > > > > for (i = 0; i < ARRAY_SIZE (isa_names_table); i++)
> > > > > > if (isa_names_table[i].option)
> > > > > >
> > > > > > 2. Some feature has a different name in the command-line option.
> > > > > >
> > > > > > ISA_NAMES_TABLE_ENTRY("fxsave", FEATURE_FXSAVE, P_ZERO, "-mfxsr")
> > > > >
> > > > > I noticed that, one can theoretically use "" for an option that does
> > > > > not
> > > > > have a flag. And NULL for these which have option equal to "-m" +
> > > > > name.
> > > > > Anyway, that's a nit.
> > > > >
> > > > > I support the patch!
> > > > > Martin
> > > > >
> > > > > >
> > > > > > Here is the updated patch. OK for master?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > >
> > > >
> > > > PING:
> > > >
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546522.html
> > > >
> > >
> > > PING.
> >
> > Hi,
> >
> > We have patches like
> >
> > https://gcc.gnu.org/pipermail/gcc-bugs/2020-June/705851.html
> >
> > queued up because of this prerequisite patch. Are there any objections
> > to this patch?
>
> Yes, there are my objections.
>
> As explained before, I support unifying libgcc and core gcc handling,
> but _NOT_ unifying with driver-i386.c. Unifying libgcc and core gcc
> handling would have benefit to avoid desynchronisation between the two
> (which happened multiple times in the past, resulting in various API
> issues). OTOH, unifying with driver-i386.c would result in quite messy
> approach, because driver-i386 handles more targets beside relatively
> recent 64bit Intel and AMD targets, not to mention heuristics to
> determine the most appropriate target when standard detection fails
> (e.g. emulators).
Only the duplicated parts of driver-i386.c should be unified. The only impact
should be removing code duplications. If it isn't the case, it is a bug in my
implementation.
--
H.J.
