Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

Hi,
(tech-toolchain@ added to cc)

On 2020/10/16 1:49, Kamil Rytarowski wrote:
> On 15.10.2020 17:14, Rin Okuyama wrote:
> > On 2020/10/15 16:12, matthew green wrote:
> > > Martin Husemann writes:
> > > > On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> > > > > you could try reverting most of our changes to this file and
> > > > > making sure you run with /proc mounted -o linux.  ryo@ recently
> > > > > added additional /proc/cpuinfo support that should make this
> > > > > just work with the upstream version, but i haven't had chance
> > > > > to update and see if this is the case.
> >
> > I've confirmed that -mtune=native works fine at least for A53,
> > even if all the local changes to driver-aarch64.c is reverted.
> > I will commit it soon.
> >
> > > > If we go this route, we should make the relevant procfs nodes
> > > > independent
> > > > of -o linux.
> > >
> > > that would be fine by me.
> >
> > Nowadays, -o linux is turned on by default (unless nolinux is
> > specified explicitly). Still, native apps probably should not
> > depend on it.
> >
> > This needs MI changes to procfs, not MD to aarch64. Should we
> > enable /proc/cpuinfo unconditionally?
>
>
> I'm against the policy of restoring the /proc dependency for this corner
> case in one application.
>
> We need to upstream the NetBSD specific patches to mainline GCC.

I'm also one who feels hesitate to import Linux'ism into our basic
components. However, for this problem in particular, I still think
it is not a good choice to keep NetBSD support in driver-aarch64.c:

(a) Our sysctl(3)-based interface is not compliant to any standards,
    just like Linux's /proc/cpuinfo. But the latter is, unfortunately
    for us, the de facto standard.

(b) Because of (a), driver-aarch64.c is deeply depended on
    /proc/cpuinfo. Our NetBSD support code

see diff to vendor branch here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/config/aarch64/driver-aarch64.c.diff?r1=1.1.1.7&r2=1.10&f=h

    is something like a "glue code" which converts our convention to
    /proc/cpuinfo style. We already do this in procfs. Why twice?

(c) I imagine that there would be little benefits for upstream to
    merge NetBSD support into their repository. If they will merge,
    I don't think the code is kept updated.

(d) Only -march=native and -mtune=native depends on this feature. I'm
    OK with /proc/cpuinfo is left as is; only enabled when -onolinux is
    not specified. IMO, it is users' responsibility that such a
    additional feature fails with their non-standard system settings.

In short, I'm worried about future when mrg@ or someone else have to
maintain our glue code eternally, if this code is not reverted.

Thanks,
rin