re: CVS commit: src/external/gpl3/gcc/dist/gcc/config
"Jared D. McNeill" writes: > Module Name: src > Committed By: jmcneill > Date: Sat Sep 18 10:45:11 UTC 2021 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config: host-darwin.c > src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64.h > > Log Message: > Fix build on macOS 11.6 arm64 hosts. > > > To generate a diff of this commit: > cvs rdiff -u -r1.1.1.10 -r1.2 \ > src/external/gpl3/gcc/dist/gcc/config/host-darwin.c > cvs rdiff -u -r1.1.1.13 -r1.2 \ > src/external/gpl3/gcc/dist/gcc/config/aarch64/aarch64.h the 2nd change here likely broke netbsd, which also has support for this. it's probably fine to add || __NetBSD__ to this conditional since those are the only two ports that support this feature. .mrg.
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&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
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/m68k
Sorry for the late reply. On 2020/08/11 1:16, Valery Ushakov wrote: This sounds eerily similar to port-macppc/54827 - there's quite a bit of confusion early on on my part there, but scroll to the last couple of mails. http://gnats.netbsd.org/54827 It looks like some logic changed in MI gcc8 that broke netbsd MD config headers and I wonder if you see the same problem here. For macppc the fix was also to undo the netbsd change to STACK_BOUNDARY in favor of PREFERRED_STACK_BOUNDARY. Thank you for remaining me that PR. I was following discussion at that time, but I'd forgotten that it was due to STACK_BOUNDARY. On 2020/08/11 10:27, matthew green wrote: May be we should also check other ports for similar gotcha proactively? good idea. no other gcc/config/*/*netbsd* files define the nasty STACK_BOUNDARY macro so hopefully we're good now. Yes, powerpc and m68k were the last ones. We somehow gained a bit more experience to overcome troubles caused by GCC. I think that we can deal with similar problems better in the next time :). Thanks, rin
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k
> May be we should also check other ports for similar gotcha proactively? good idea. no other gcc/config/*/*netbsd* files define the nasty STACK_BOUNDARY macro so hopefully we're good now. thanks! .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k
On Mon, Aug 10, 2020 at 06:24:39 +, Rin Okuyama wrote: > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/m68k: netbsd-elf.h > > Log Message: > PR port-m68k/6 > > Reset STACK_BOUNDARY to default, 16, to fix strange freeze for amiga, > when kernel is compiled by GCC8. This sounds eerily similar to port-macppc/54827 - there's quite a bit of confusion early on on my part there, but scroll to the last couple of mails. http://gnats.netbsd.org/54827 It looks like some logic changed in MI gcc8 that broke netbsd MD config headers and I wonder if you see the same problem here. For macppc the fix was also to undo the netbsd change to STACK_BOUNDARY in favor of PREFERRED_STACK_BOUNDARY. May be we should also check other ports for similar gotcha proactively? -uwe
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.
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config
"Maya Rashish" writes: > Module Name: src > Committed By: maya > Date: Wed Apr 10 16:11:06 UTC 2019 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config: netbsd.h > > Log Message: > remove bogus specs redefinition. > fixes the use of -march=native please revert this. the right fix is to fix the x86 specific code which i have a change in testing for. .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Thu, Jan 03, 2013 at 03:46:08PM +0100, Joerg Sonnenberger wrote: > > > > > > At least in terms of documentation, this is a regression. TARGET_64BIT > > > implies the presence of SSE support and that's somewhat independent of > > > the separate preferred stack boundary > > > > Eh? TARGET_64BIT forces ix86_preferred_stack_boundary >= 64. > > The fact that it also implies SSE support is relevant. > > Only as default value, not if explicitly overriden? It won't let you override to a lower value. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Mon, Dec 31, 2012 at 10:08:18AM +, David Laight wrote: > On Mon, Dec 31, 2012 at 03:00:42AM +0100, Joerg Sonnenberger wrote: > > On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: > > > Module Name: src > > > Committed By: dsl > > > Date: Sun Dec 30 20:16:59 UTC 2012 > > > > > > Modified Files: > > > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c > > > > > > Log Message: > > > No need to check both TARGET_64BIT and ix86_preferred_stack_boundary >= > > > 64, > > > if the former is true the latter is also true. > > > > At least in terms of documentation, this is a regression. TARGET_64BIT > > implies the presence of SSE support and that's somewhat independent of > > the separate preferred stack boundary > > Eh? TARGET_64BIT forces ix86_preferred_stack_boundary >= 64. > The fact that it also implies SSE support is relevant. Only as default value, not if explicitly overriden? Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Tue, Jan 01, 2013 at 02:06:31AM +1100, matthew green wrote: > > > Module Name:src > > Committed By: dsl > > Date: Sun Dec 30 20:16:59 UTC 2012 > > > > Modified Files: > > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c > > > > Log Message: > > No need to check both TARGET_64BIT and ix86_preferred_stack_boundary >= 64, > > if the former is true the latter is also true. > > can this not be overriden with cli options? the old > test seems safer. No - for amd64 the ix86_preferred_stack_boundary is always >= 64. David -- David Laight: da...@l8s.co.uk
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
> Module Name: src > Committed By: dsl > Date: Sun Dec 30 20:16:59 UTC 2012 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c > > Log Message: > No need to check both TARGET_64BIT and ix86_preferred_stack_boundary >= 64, > if the former is true the latter is also true. can this not be overriden with cli options? the old test seems safer.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Mon, Dec 31, 2012 at 03:00:42AM +0100, Joerg Sonnenberger wrote: > On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: > > Module Name:src > > Committed By: dsl > > Date: Sun Dec 30 20:16:59 UTC 2012 > > > > Modified Files: > > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c > > > > Log Message: > > No need to check both TARGET_64BIT and ix86_preferred_stack_boundary >= 64, > > if the former is true the latter is also true. > > At least in terms of documentation, this is a regression. TARGET_64BIT > implies the presence of SSE support and that's somewhat independent of > the separate preferred stack boundary Eh? TARGET_64BIT forces ix86_preferred_stack_boundary >= 64. The fact that it also implies SSE support is relevant. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: > Module Name: src > Committed By: dsl > Date: Sun Dec 30 20:16:59 UTC 2012 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c > > Log Message: > No need to check both TARGET_64BIT and ix86_preferred_stack_boundary >= 64, > if the former is true the latter is also true. At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Mon, Oct 08, 2012 at 08:12:26AM +0100, David Laight wrote: > On Sat, Oct 06, 2012 at 02:10:46PM +, Joerg Sonnenberger wrote: > > Module Name:src > > Committed By: joerg > > Date: Sat Oct 6 14:10:46 UTC 2012 > > > > Modified Files: > > src/external/gpl3/gcc/dist/gcc/config/i386: i386.h > > > > Log Message: > > PR 46978: ICE on spilling MMX registers > > > > GCC/i386 has code to lower the required alignment for long long to 32bit > > as the CPU doesn't need more. It is also using the same mode for setting > > up the MMX registers and in turn, the stack slots reserved for spilling > > require 32bit alignment. The actual vector types used keep the original > > 64bit alignment, so when the compiler wants to spill a MMX register, it > > hits an assertion. Fix this by using the vector type as raw type for MMX > > registers. > > Doesn't that enforce a 64bit alignment when it isn't needed? Correct. Given the general usefulness of MMX, I'm inclined to just ignore it. > Misaligned transfers for stack slots for MMX are actually fine. Also correct. I haven't had time to hunt down where it comes up with that assumption though. Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Sat, Oct 06, 2012 at 02:10:46PM +, Joerg Sonnenberger wrote: > Module Name: src > Committed By: joerg > Date: Sat Oct 6 14:10:46 UTC 2012 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/i386: i386.h > > Log Message: > PR 46978: ICE on spilling MMX registers > > GCC/i386 has code to lower the required alignment for long long to 32bit > as the CPU doesn't need more. It is also using the same mode for setting > up the MMX registers and in turn, the stack slots reserved for spilling > require 32bit alignment. The actual vector types used keep the original > 64bit alignment, so when the compiler wants to spill a MMX register, it > hits an assertion. Fix this by using the vector type as raw type for MMX > registers. Doesn't that enforce a 64bit alignment when it isn't needed? Or have I misread the commit message? Misaligned transfers for stack slots for MMX are actually fine. Only the 128bit (and larger) accesses have to be aligned. The performance penalty of misaligned 64bit transfers really is best avoided by maintaining the stack alignment - and assuming it won't get misaligned. I suspect that the 'sub %sp,n' use to allocate a stack frame has hardware optimisations that are absent from the 'and %sp,~7' needed to realign it. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Fri, Sep 14, 2012 at 01:00:01PM +, Joerg Sonnenberger wrote: > Module Name: src > Committed By: joerg > Date: Fri Sep 14 13:00:01 UTC 2012 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c netbsd-elf.h > netbsd64.h > > Log Message: > Fix GCC to correctly implement the i386 psABI on NetBSD. > This consists of two parts: > - for NetBSD/i386 and NetBSD/AMD64 with -m32, use a default stack > alignment of 23bit as specified by the ABI > - ensure that double and long long variables on the stack are by default > only aligned to 32bit, if there is nothing else in the function > needing a larger stack alignment > > The combination ensures that SSE variables on the stack trigger the > realignment logic, but just using double or long long doesn't. > > > To generate a diff of this commit: > cvs rdiff -u -r1.1.1.1 -r1.2 \ > src/external/gpl3/gcc/dist/gcc/config/i386/i386.c \ > src/external/gpl3/gcc/dist/gcc/config/i386/netbsd64.h > cvs rdiff -u -r1.2 -r1.3 \ > src/external/gpl3/gcc/dist/gcc/config/i386/netbsd-elf.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. I'm still to be convinced that the patches are correct. David -- David Laight: da...@l8s.co.uk
