CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Module Name:src Committed By: mrg Date: Mon Feb 20 01:16:38 UTC 2023 Modified Files: src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64-netbsd.h Log Message: add author info to this file. To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 \ src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Module Name:src Committed By: mrg Date: Mon Feb 20 01:16:38 UTC 2023 Modified Files: src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64-netbsd.h Log Message: add author info to this file. To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 \ src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h diff -u src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h:1.6 src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h:1.7 --- src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h:1.6 Tue Jul 13 06:56:24 2021 +++ src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64-netbsd.h Mon Feb 20 01:16:38 2023 @@ -1,5 +1,7 @@ /* Definitions for AArch64 running NetBSD Copyright (C) 2016-2020 Free Software Foundation, Inc. + Contributed by Matthew Green (m...@eterna.com.au) and Christos Zoulas + (chris...@netbsd.org.) This file is part of GCC.
CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Module Name:src Committed By: jmcneill Date: Sat Sep 18 19:59:11 UTC 2021 Modified Files: src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64.h Log Message: oops, re-enable host_detect_local_cpu for NetBSD To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3 \ src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Module Name:src
Committed By: jmcneill
Date: Sat Sep 18 19:59:11 UTC 2021
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64.h
Log Message:
oops, re-enable host_detect_local_cpu for NetBSD
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 \
src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h
diff -u src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h:1.2 src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h:1.3
--- src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h:1.2 Sat Sep 18 10:45:11 2021
+++ src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h Sat Sep 18 19:59:11 2021
@@ -1200,7 +1200,7 @@ extern const char *aarch64_rewrite_mcpu
#define MCPU_TO_MARCH_SPEC_FUNCTIONS \
{ "rewrite_mcpu", aarch64_rewrite_mcpu },
-#if defined(__aarch64__) && defined(__linux__)
+#if defined(__aarch64__) && (defined(__linux__) || defined(__NetBSD__))
extern const char *host_detect_local_cpu (int argc, const char **argv);
#define HAVE_LOCAL_CPU_DETECT
# define EXTRA_SPEC_FUNCTIONS \
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote: > 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. It works properly in a chroot etc without needing new files. I would call that a big plus. Joerg
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=1.10=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
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Date:Fri, 16 Oct 2020 04:07:31 + From:"Thomas Mueller" Message-ID: <20201016052422.e063084...@mail.netbsd.org> | Should I add ,linux to the end of the procfs line? You can, but it isn't needed these days -- I used to mount procfs twice, once without the linux option, on /proc, and once with, on /emul/linux/proc) but there seems to be little point in that any more (even though the linux /proc has a whole bunch of trash that has nothing to do with processes, and should be, and generally is, available from /kern ... /proc/cpuinfo is an example of that, though that one is missing from kernfs and should be added there). I do add "hidden" to the mount option list though, there's essentially no point in including /proc /kern /dev/pts (or anything else like those) in default df output (which is the only thing "hidden" generally affects). kre
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Excerpt from Rin Okuyama: > 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? My NetBSD system has no /kern and no /proc, do I need to mkdir these directories? I just did. kernfs and procfs were commented out in /etc/fstab . Do I need to revive, new /etc/fstab being as shown below, is this good now? Should I add ,linux to the end of the procfs line? I might want to run Linux programs. # NetBSD /targetroot/etc/fstab # See /usr/share/examples/fstab/ for more examples. NAME=WD2G19 / ffs rw,log 1 1 NAME=WD2G17 none swapsw,dp0 0 kernfs /kern kernfs rw ptyfs /dev/ptsptyfs rw procfs /proc procfs rw /dev/cd0a /cdrom cd9660 ro,noauto tmpfs /var/shmtmpfs rw,-m1777,-sram%25 Tom
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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 had to write the netbsd version of that code twice so far. once for gcc 8.3 and 8.4, once for gcc 8.5 and 9.3, and i'd really rather avoid having to write another version :) Oh... Thank you very much for your hard works! Thanks, rin
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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. > > If we go this route, we should make the relevant procfs nodes independent > of -o linux. that would be fine by me. i had to write the netbsd version of that code twice so far. once for gcc 8.3 and 8.4, once for gcc 8.5 and 9.3, and i'd really rather avoid having to write another version :) .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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. If we go this route, we should make the relevant procfs nodes independent of -o linux. Martin
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Tue Oct 13 07:12:00 UTC 2020 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c > > Log Message: > Reduce diff with upstream a bit. > No functional changes. 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. thanks! .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Unfortunately this breaks building on a 9.0 arm64 host because it is
picking up /usr/include/aarch64/armreg.h and the one in 9.0 is missing a
bunch of stuff. It works when using armreg.h from the source tree instead,
eg:
-#include
+#include "/path/to/src/sys/arch/aarch64/include/armreg.h"
On Tue, 28 Apr 2020, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Tue Apr 28 03:00:23 UTC 2020
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c
Log Message:
slightly reduce the scope of #ifdef __NetBSD__ version of the
-m{cpu,tune,arch}=native handling code, and hopefully reduce
future effort by aligning inputs
- share common variables and setup more
- build a linux/arm64 like /proc/cpuinfo Features line and
use that to match the new 'list of features' per gcc feature,
based upon our sysctl(2) published info. complete this list
for all supported extensions.
now this feature works again.
To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 \
src/external/gpl3/gcc/dist/gcc/config/aarch64/driver-aarch64.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
