tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index