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/ginclude
> On Jul 15, 2021, at 12:06 AM, matthew green wrote: > > "Christos Zoulas" writes: >> Module Name: src >> Committed By:christos >> Date:Wed Jul 14 13:24:59 UTC 2021 >> >> Modified Files: >> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h >> >> Log Message: >> clang does not support __float128 in our configuration and i386 > > shouldn't you replace this with some other 128-bit aligned > value then, instead of eliding it entirely? Good idea! Let me do that. christos signature.asc Description: Message signed with OpenPGP
re: CVS commit: src/external/gpl3/gcc/dist/gcc/ginclude
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Wed Jul 14 13:24:59 UTC 2021 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h > > Log Message: > clang does not support __float128 in our configuration and i386 shouldn't you replace this with some other 128-bit aligned value then, instead of eliding it entirely? .mrg.
Re: CVS commit: src/external/gpl3/gcc/usr.bin/cc1plus
The condition is reversed. I will fix.
christos
> On Apr 26, 2021, at 10:31 PM, Rin Okuyama wrote:
>
> Hi,
>
> On 2021/04/26 7:25, Christos Zoulas wrote:
>> --- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11
>> 20:05:56 2021
>> +++ src/external/gpl3/gcc/usr.bin/cc1plus/Makefile Sun Apr 25 18:25:55 2021
> (snip)
>> -.if ${MACHINE_ARCH} == "mipseb" || ${MACHINE_ARCH} == "mipsel"
>> +.if ${MACHINE_MIPS64}
>> COPTS.c-common.c+=-O3
>> .endif
>
> This was hack for mips32:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/usr.bin/cc1plus/Makefile#rev1.12
>
> Does mips64 require it? Also for
> external/gpl3/gcc/usr.bin/cc1objplus/Makefile.
>
> Thanks,
> rin
signature.asc
Description: Message signed with OpenPGP
Re: CVS commit: src/external/gpl3/gcc/usr.bin/cc1plus
Hi,
On 2021/04/26 7:25, Christos Zoulas wrote:
--- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11 20:05:56 2021
+++ src/external/gpl3/gcc/usr.bin/cc1plus/Makefile Sun Apr 25 18:25:55 2021
(snip)
-.if ${MACHINE_ARCH} == "mipseb" || ${MACHINE_ARCH} == "mipsel"
+.if ${MACHINE_MIPS64}
COPTS.c-common.c+=-O3
.endif
This was hack for mips32:
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/usr.bin/cc1plus/Makefile#rev1.12
Does mips64 require it? Also for external/gpl3/gcc/usr.bin/cc1objplus/Makefile.
Thanks,
rin
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
On 12.09.2020 23:36, Joerg Sonnenberger wrote: > On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote: >> On 12.09.2020 22:06, Joerg Sonnenberger wrote: >>> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: On 11.09.2020 23:38, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: >> The current code is confusing, as it attempts to use unimplemented >> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in >> other _lwp_getprivate(). This caused my confusion... as I assumed that >> _lwp_getprivate_fast() is internal and _lwp_getprivate() for public >> consumption. > > _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > There is __lwp_getprivate_fast, which originally wasn't implemented on > architectures without a fast path (like VAX). Nowadays, all functional > ports provide either __lwp_getprivate_fast (potentially with a fall-back > to the system call) or __lwp_gettcb_fast. The difference is whether the > TLS register is biased or not. > Do you agree with this patch: http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt >>> >>> No, I don't see the point. >>> >> >> What's the alternative to use in 3rd party code? > > Why do you need an alternative? > I need tls_tcb of the calling thread. https://github.com/llvm/llvm-project/blob/15b37e1cfa5f09af376a47a1bc67d67bb5c7848b/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L406 https://github.com/llvm/llvm-project/blob/15b37e1cfa5f09af376a47a1bc67d67bb5c7848b/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L458 What is the interface (ideally MI) for this for 3rd party code? > Joerg > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc
On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote: > On 12.09.2020 22:06, Joerg Sonnenberger wrote: > > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: > >> On 11.09.2020 23:38, Joerg Sonnenberger wrote: > >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > The current code is confusing, as it attempts to use unimplemented > _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in > other _lwp_getprivate(). This caused my confusion... as I assumed that > _lwp_getprivate_fast() is internal and _lwp_getprivate() for public > consumption. > >>> > >>> _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > >>> There is __lwp_getprivate_fast, which originally wasn't implemented on > >>> architectures without a fast path (like VAX). Nowadays, all functional > >>> ports provide either __lwp_getprivate_fast (potentially with a fall-back > >>> to the system call) or __lwp_gettcb_fast. The difference is whether the > >>> TLS register is biased or not. > >>> > >> > >> Do you agree with this patch: > >> > >> http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt > > > > No, I don't see the point. > > > > What's the alternative to use in 3rd party code? Why do you need an alternative? Joerg
Re: CVS commit: src/external/gpl3/gcc
On 12.09.2020 22:06, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: >> On 11.09.2020 23:38, Joerg Sonnenberger wrote: >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: The current code is confusing, as it attempts to use unimplemented _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in other _lwp_getprivate(). This caused my confusion... as I assumed that _lwp_getprivate_fast() is internal and _lwp_getprivate() for public consumption. >>> >>> _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. >>> There is __lwp_getprivate_fast, which originally wasn't implemented on >>> architectures without a fast path (like VAX). Nowadays, all functional >>> ports provide either __lwp_getprivate_fast (potentially with a fall-back >>> to the system call) or __lwp_gettcb_fast. The difference is whether the >>> TLS register is biased or not. >>> >> >> Do you agree with this patch: >> >> http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt > > No, I don't see the point. > What's the alternative to use in 3rd party code? > Joerg > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc
On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: > On 11.09.2020 23:38, Joerg Sonnenberger wrote: > > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > >> The current code is confusing, as it attempts to use unimplemented > >> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in > >> other _lwp_getprivate(). This caused my confusion... as I assumed that > >> _lwp_getprivate_fast() is internal and _lwp_getprivate() for public > >> consumption. > > > > _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > > There is __lwp_getprivate_fast, which originally wasn't implemented on > > architectures without a fast path (like VAX). Nowadays, all functional > > ports provide either __lwp_getprivate_fast (potentially with a fall-back > > to the system call) or __lwp_gettcb_fast. The difference is whether the > > TLS register is biased or not. > > > > Do you agree with this patch: > > http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt No, I don't see the point. Joerg
Re: CVS commit: src/external/gpl3/gcc
On 11.09.2020 23:38, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: >> The current code is confusing, as it attempts to use unimplemented >> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in >> other _lwp_getprivate(). This caused my confusion... as I assumed that >> _lwp_getprivate_fast() is internal and _lwp_getprivate() for public >> consumption. > > _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. > There is __lwp_getprivate_fast, which originally wasn't implemented on > architectures without a fast path (like VAX). Nowadays, all functional > ports provide either __lwp_getprivate_fast (potentially with a fall-back > to the system call) or __lwp_gettcb_fast. The difference is whether the > TLS register is biased or not. > Do you agree with this patch: http://netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt And then, using _rtld_tls_self() in sanitizers (and wherever someone finds it useful)? As an alternative we will use __lwp_gettcb_fast() or __lwp_getprivate_fast() manually in 3rd party code, which seems fragile. > Joerg > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc
On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > The current code is confusing, as it attempts to use unimplemented > _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in > other _lwp_getprivate(). This caused my confusion... as I assumed that > _lwp_getprivate_fast() is internal and _lwp_getprivate() for public > consumption. _PTHREAD_GETTCB_EXT is a rump hack. There is no _lwp_getprivate_fast. There is __lwp_getprivate_fast, which originally wasn't implemented on architectures without a fast path (like VAX). Nowadays, all functional ports provide either __lwp_getprivate_fast (potentially with a fall-back to the system call) or __lwp_gettcb_fast. The difference is whether the TLS register is biased or not. Joerg
Re: CVS commit: src/external/gpl3/gcc
On 11.09.2020 07:13, Rin Okuyama wrote:
> Hi again,
>
> On 2020/09/10 21:53, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By: kamil
>> Date: Thu Sep 10 12:53:06 UTC 2020
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
>> sanitizer_linux_libcdep.cc
>> src/external/gpl3/gcc/lib: Makefile.sanitizer
>>
>> Log Message:
>> Avoid using internal RTLD/libpthread/libc symbol in sanitizers
>>
> ...
>> Index:
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>>
>> diff -u
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.15
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.16
>>
>> ---
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.15
>>
>> Mon Sep 7 07:10:43 2020
>> +++
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>>
>> Thu Sep 10 12:53:05 2020
>> @@ -47,6 +47,7 @@
>> #if SANITIZER_NETBSD
>> #include
>> #include
>> +#include
>> #endif
>> #if SANITIZER_SOLARIS
>> @@ -417,13 +418,7 @@ uptr ThreadSelf() {
>> #if SANITIZER_NETBSD
>> static struct tls_tcb * ThreadSelfTlsTcb() {
>> - struct tls_tcb * tcb = NULL;
>> -# ifdef __HAVE___LWP_GETTCB_FAST
>> - tcb = (struct tls_tcb *)__lwp_gettcb_fast();
>> -# elif defined(__HAVE___LWP_GETPRIVATE_FAST)
>> - tcb = (struct tls_tcb *)__lwp_getprivate_fast();
>> -# endif
>> - return tcb;
>> + return (struct tls_tcb *)_lwp_getprivate();
>> }
>> uptr ThreadSelf() {
>>
>
> This change breaks at least mips and powerpc, in which the return value of
> __lwp_getprivate(2), i.e., curlwp->l_private is not tcb address itself, but
> biased one. On the other hand, the return value of __lwp_gettcb_fast() is
> unbiased address; see sys/arch/{mips,powerpc}/include/mcontext.h.
>
> For powerpc, I recently attempted to change l_private to store tcb address
> itself:
>
> http://www.nerv.org/netbsd/?q=id:20200621T004000Z.95c1a18070b53713ce2c763df7f40743bf74172c
>
>
> But I reverted it soon as requested by joerg:
>
> http://www.nerv.org/netbsd/?q=id:20200622T053457Z.05db3be87b5ad499f5d1adba755bc573fd241c87
>
>
> His reasoning was that kernel must not know the ABI details in userland.
> I fully agree with this. See above links for more details.
>
> Thanks,
> rin
Thank you for noting it!
This is strange as I assumed that _lwp_getprivate() returns always the
correct private pointer and it is abstraction over fast ABI specific
calls . Also the usage of _lwp_getprivate() was suggested by Joerg back
then in sanitizers.
So we want exported to userland functionality to get the tls_tcb
pointer, something without using the internal RTLS/LIBPTHREAD/LIBC
namespaces.
The current code is confusing, as it attempts to use unimplemented
_PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in
other _lwp_getprivate(). This caused my confusion... as I assumed that
_lwp_getprivate_fast() is internal and _lwp_getprivate() for public
consumption.
https://nxr.netbsd.org/xref/src/lib/libpthread/pthread_int.h#266
263 static inline pthread_t __constfunc
264 pthread__self(void)
265 {
266 #if defined(_PTHREAD_GETTCB_EXT)
267 struct tls_tcb * const tcb = _PTHREAD_GETTCB_EXT();
268 #elif defined(__HAVE___LWP_GETTCB_FAST)
269 struct tls_tcb * const tcb = __lwp_gettcb_fast();
270 #else
271 struct tls_tcb * const tcb = __lwp_getprivate_fast();
272 #endif
273 return (pthread_t)tcb->tcb_pthread;
274 }
https://nxr.netbsd.org/xref/src/lib/libpthread/pthread.c#1268
1268 #if defined(_PTHREAD_GETTCB_EXT)
1269 pthread__main->pt_tls = _PTHREAD_GETTCB_EXT();
1270 #elif defined(__HAVE___LWP_GETTCB_FAST)
1271 pthread__main->pt_tls = __lwp_gettcb_fast();
1272 #else
1273 pthread__main->pt_tls = _lwp_getprivate();
1274 #endif
1275 pthread__main->pt_tls->tcb_pthread = pthread__main;
https://nxr.netbsd.org/xref/src/libexec/ld.elf_so/tls.c#294
293 #ifdef __HAVE___LWP_GETTCB_FAST
294 struct tls_tcb * const tcb = __lwp_gettcb_fast();
295 #else
296 struct tls_tcb * const tcb = __lwp_getprivate_fast();
297 #endif
1. Could we please synchronize above three code chunks, avoiding the
situation of having each of them implemented differently?
2. Could we please export _rtld_tls_self() or something similar and
register in ?
Does this patch look good?
https://www.netbsd.org/~kamil/patch-00278-_rtld_tls_self.txt
In the worst case I will need to reexpose internal APIs in sanitizers
and pick one of the above tls_tcb retrieval implementations and use in
LLVM/GCC sanitizers.
PS. There is an ongoing GCC and Linux kernel discussion on a related
topic in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 "Implement
__builtin_thread_pointer() and
Re: CVS commit: src/external/gpl3/gcc
Hi again,
On 2020/09/10 21:53, Kamil Rytarowski wrote:
Module Name:src
Committed By: kamil
Date: Thu Sep 10 12:53:06 UTC 2020
Modified Files:
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
sanitizer_linux_libcdep.cc
src/external/gpl3/gcc/lib: Makefile.sanitizer
Log Message:
Avoid using internal RTLD/libpthread/libc symbol in sanitizers
...
Index:
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
diff -u
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.15
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.16
---
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.15
Mon Sep 7 07:10:43 2020
+++
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
Thu Sep 10 12:53:05 2020
@@ -47,6 +47,7 @@
#if SANITIZER_NETBSD
#include
#include
+#include
#endif
#if SANITIZER_SOLARIS
@@ -417,13 +418,7 @@ uptr ThreadSelf() {
#if SANITIZER_NETBSD
static struct tls_tcb * ThreadSelfTlsTcb() {
- struct tls_tcb * tcb = NULL;
-# ifdef __HAVE___LWP_GETTCB_FAST
- tcb = (struct tls_tcb *)__lwp_gettcb_fast();
-# elif defined(__HAVE___LWP_GETPRIVATE_FAST)
- tcb = (struct tls_tcb *)__lwp_getprivate_fast();
-# endif
- return tcb;
+ return (struct tls_tcb *)_lwp_getprivate();
}
uptr ThreadSelf() {
This change breaks at least mips and powerpc, in which the return value of
__lwp_getprivate(2), i.e., curlwp->l_private is not tcb address itself, but
biased one. On the other hand, the return value of __lwp_gettcb_fast() is
unbiased address; see sys/arch/{mips,powerpc}/include/mcontext.h.
For powerpc, I recently attempted to change l_private to store tcb address
itself:
http://www.nerv.org/netbsd/?q=id:20200621T004000Z.95c1a18070b53713ce2c763df7f40743bf74172c
But I reverted it soon as requested by joerg:
http://www.nerv.org/netbsd/?q=id:20200622T053457Z.05db3be87b5ad499f5d1adba755bc573fd241c87
His reasoning was that kernel must not know the ABI details in userland.
I fully agree with this. See above links for more details.
Thanks,
rin
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common
On 05.09.2020 15:35, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Sat Sep 5 13:35:55 UTC 2020
>
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
> sanitizer_linux.cc sanitizer_linux.h sanitizer_linux_libcdep.cc
> sanitizer_platform_limits_netbsd.cc sanitizer_syscall_generic.inc
>
> Log Message:
> fix various merge botches; we may need to re-port the ThreadLister code.
>
LSan was ported and upstreamed post GCC-9:
https://github.com/llvm/llvm-project/commit/1b58389428ed07a7322ba9c2bcaeec99807f9457
https://github.com/llvm/llvm-project/commit/5fe1e55d35413b1904cfcf16ec15495398921fe5
https://github.com/llvm/llvm-project/commit/8827047551570b7ed7088765c3de2a8cce6823b8
https://github.com/llvm/llvm-project/commit/983d7ddd0b278b45d815cbac9197205b39c4860a
https://github.com/llvm/llvm-project/commit/fc356dcc11c10003ff22acff667b0a9f5e6c1e0f
https://github.com/llvm/llvm-project/commit/3a189bac9bb111c9a59339015ab0d4e2fed735f4
https://github.com/llvm/llvm-project/commit/02519fc7a6f8c528f67975a9f78ce64dabf402b4
And possibly something else:
https://github.com/llvm/llvm-project/commits?author=krytarowski
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.33 -r1.34 \
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc
> cvs rdiff -u -r1.9 -r1.10 \
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.h
> cvs rdiff -u -r1.12 -r1.13 \
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> cvs rdiff -u -r1.1.1.2 -r1.2 \
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_platform_limits_netbsd.cc
> cvs rdiff -u -r1.8 -r1.9 \
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc
>
> 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/libsanitizer/sanitizer_common/sanitizer_linux.cc
> diff -u
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc:1.33
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc:1.34
> ---
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc:1.33
> Sat Sep 5 09:12:32 2020
> +++
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc
> Sat Sep 5 13:35:55 2020
> @@ -41,8 +41,6 @@
> #undef stat
> #endif
>
> -#endif // SANITIZER_LINUX
> -
> #if SANITIZER_NETBSD
> #include
> #endif
> @@ -980,7 +978,6 @@ ThreadLister::ThreadLister(pid_t pid) :
>if (internal_iserror(descriptor_)) {
> Report("Can't open /proc/%d/task for reading.\n", pid);
>}
> -#endif
> }
>
> ThreadLister::Result ThreadLister::ListThreads(
> @@ -1055,10 +1052,8 @@ bool ThreadLister::IsAlive(int tid) {
> }
>
> ThreadLister::~ThreadLister() {
> -#ifndef SANITIZER_NETBSD
>if (!internal_iserror(descriptor_))
> internal_close(descriptor_);
> -#endif
> }
> #endif
>
>
> Index:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.h
> diff -u
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.h:1.9
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.h:1.10
> ---
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.h:1.9
> Sat Sep 5 09:12:32 2020
> +++
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.h
> Sat Sep 5 13:35:55 2020
> @@ -69,6 +69,8 @@ uptr internal_clone(int (*fn)(void *), v
> #endif
> #elif SANITIZER_FREEBSD
> void internal_sigdelset(__sanitizer_sigset_t *set, int signum);
> +#elif SANITIZER_NETBSD
> +uptr internal_prctl(int option, uptr arg2, uptr arg3, uptr arg4, uptr arg5);
> #endif // SANITIZER_LINUX
>
> #ifdef SANITIZER_NETBSD
>
> Index:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> diff -u
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.12
>
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.13
> ---
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:1.12
> Sat Sep 5 09:12:32 2020
> +++
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>Sat Sep 5 13:35:55 2020
> @@ -72,6 +72,10 @@ struct __sanitizer::linux_dirent {
> #include
> #endif
>
> +#if SANITIZER_NETBSD
> +#include
> +#endif
> +
> namespace __sanitizer {
>
> SANITIZER_WEAK_ATTRIBUTE int
>
> Index:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_platform_limits_netbsd.cc
> diff -u
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_platform_limits_netbsd.cc:1.1.1.2
>
>
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/usr.bin/host-libcpp
> Modified Files: > src/external/gpl3/gcc/usr.bin/host-libcpp: Makefile > > Log Message: > PR bin/55411 (Akihiko HAYASHI) > > Remove stray ``&&'' introduced in the previous revision, so that > host tools are correctly passed to configure script. > > No similar problem for gcc.old. No release branches are affected. thanks!
Re: CVS commit: src/external/gpl3/gcc
On 2020/06/02 17:03, matthew green wrote: Module Name:src Committed By: mrg Date: Tue Jun 2 08:03:59 UTC 2020 Modified Files: src/external/gpl3/gcc: gcc2netbsd Log Message: don't elide fortran components. we'd like to revive g77-as-gfortran. To generate a diff of this commit: cvs rdiff -u -r1.7 -r1.8 src/external/gpl3/gcc/gcc2netbsd Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. That sounds *REALLY* great! I still use Fortran in my work ;). Thanks, rin
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/libobjc
> >> > Module Name: src > >> > Committed By:christos > >> > Date:Wed Oct 16 15:01:56 UTC 2019 > >> > > >> > Modified Files: > >> > src/external/gpl3/gcc/dist/libobjc: encoding.c > >> > > >> > Log Message: > >> > prevent DFmode re-definition. > >> > >> i'm not a fan of this one. i'd like to figure out > >> what is really happening here.. > >> > >> i've been using the same hack, but i didn't want to > >> commit it because i don't understand it. > >> > >> > >> .mrg. > > > >I'd like to note that upstream adopted the same choice. > >https://gcc.gnu.org/viewcvs/gcc?view=revision=269429 > > That's what we'll keep then :-) works for me. thanks!
Re: CVS commit: src/external/gpl3/gcc/dist/libobjc
In article <20191016220250.ga23...@homeworld.netbsd.org>, wrote: >On Thu, Oct 17, 2019 at 07:08:45AM +1100, matthew green wrote: >> "Christos Zoulas" writes: >> > Module Name: src >> > Committed By: christos >> > Date: Wed Oct 16 15:01:56 UTC 2019 >> > >> > Modified Files: >> >src/external/gpl3/gcc/dist/libobjc: encoding.c >> > >> > Log Message: >> > prevent DFmode re-definition. >> >> i'm not a fan of this one. i'd like to figure out >> what is really happening here.. >> >> i've been using the same hack, but i didn't want to >> commit it because i don't understand it. >> >> >> .mrg. > >I'd like to note that upstream adopted the same choice. >https://gcc.gnu.org/viewcvs/gcc?view=revision=269429 That's what we'll keep then :-) christos
Re: CVS commit: src/external/gpl3/gcc/dist/libobjc
On Thu, Oct 17, 2019 at 07:08:45AM +1100, matthew green wrote: > "Christos Zoulas" writes: > > Module Name:src > > Committed By: christos > > Date: Wed Oct 16 15:01:56 UTC 2019 > > > > Modified Files: > > src/external/gpl3/gcc/dist/libobjc: encoding.c > > > > Log Message: > > prevent DFmode re-definition. > > i'm not a fan of this one. i'd like to figure out > what is really happening here.. > > i've been using the same hack, but i didn't want to > commit it because i don't understand it. > > > .mrg. I'd like to note that upstream adopted the same choice. https://gcc.gnu.org/viewcvs/gcc?view=revision=269429
Re: CVS commit: src/external/gpl3/gcc/dist/libobjc
In article <9715.1571256...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Oct 16 15:01:56 UTC 2019
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/libobjc: encoding.c
>>
>> Log Message:
>> prevent DFmode re-definition.
>
>i'm not a fan of this one. i'd like to figure out
>what is really happening here..
>
>i've been using the same hack, but i didn't want to
>commit it because i don't understand it.
I've looked into it:
The definition comes from:
src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64/insn-modes.h:317
#ifdef USE_ENUM_MODES
#define DFmode E_DFmode
#else
#define DFmode (scalar_float_mode ((scalar_float_mode::from_int) E_DFmode))
#endif
These defines are new in gcc8. The older gcc does not have E_DFmode,
and just uses the DFmode enum (which has now been renamed E_DFmode).
So the encoding.c has been changed to use the new E_DFmode in one place:
--- /usr/src/external/gpl3/gcc.old//dist/libobjc/encoding.c 2019-10-16
17:44:57.910551512 -0400
+++ /usr/src/external/gpl3/gcc//dist/libobjc/encoding.c 2019-10-16
17:45:05.111849735 -0400
@@ -1,5 +1,5 @@
/* Encoding of types for Objective C.
- Copyright (C) 1993-2017 Free Software Foundation, Inc.
+ Copyright (C) 1993-2018 Free Software Foundation, Inc.
Contributed by Kresten Krab Thorup
Bitfield support by Ovidiu Predescu
@@ -162,7 +162,7 @@
case UNION_TYPE:
return MAX (MAX (comp, spec), objc_alignof_type (_stp) * __CHAR_BIT__);
break;
- case DFmode:
+ case E_DFmode:
case _C_LNG_LNG:
case _C_ULNG_LNG:
return MAX (MAX (comp, spec), 64);
The only other place DFmode is used is:
/* FIXME: while this file has no business including tm.h, this
definitely has no business defining this macro but it
is only way around without really rewritting this file,
should look after the branch of 3.4 to fix this. */
#define rs6000_special_round_type_align(STRUCT, COMPUTED, SPECIFIED)\
({ const char *_fields = TYPE_FIELDS (STRUCT);\
((_fields != 0\
&& TYPE_MODE (strip_array_types (TREE_TYPE (_fields))) == DFmode) \
? MAX (MAX (COMPUTED, SPECIFIED), 64)\
: MAX (COMPUTED, SPECIFIED));})
So think that the right fix is to change the second DFmode to E_DFmode and
then delete the re-definition.
christos
re: CVS commit: src/external/gpl3/gcc/dist/libobjc
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Wed Oct 16 15:01:56 UTC 2019 > > Modified Files: > src/external/gpl3/gcc/dist/libobjc: encoding.c > > Log Message: > prevent DFmode re-definition. i'm not a fan of this one. i'd like to figure out what is really happening here.. i've been using the same hack, but i didn't want to commit it because i don't understand it. .mrg.
Re: CVS commit: src/external/gpl3/gcc
On 04.10.2019 10:51, matthew green wrote: > Module Name: src > Committed By: mrg > Date: Fri Oct 4 08:51:33 UTC 2019 > > Modified Files: > src/external/gpl3/gcc: README.gcc8 > src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64-netbsd.h > src/external/gpl3/gcc/dist/libsanitizer/lsan: lsan_allocator.cc > lsan_allocator.h > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: > sanitizer_platform_limits_netbsd.h > sanitizer_stoptheworld_linux_libcdep.cc > src/external/gpl3/gcc/dist/libsanitizer/ubsan: ubsan_handlers_cxx.cc > src/external/gpl3/gcc/lib/libsupc++: Makefile.common > src/external/gpl3/gcc/lib/libubsan: Makefile > src/external/gpl3/gcc/usr.bin/gcc/arch/aarch64: configargs.h > > Log Message: > - update README.gcc8 to include current status > - netbsd/arm64 uses 64 byte malloc alignment > - make lsan compile on sparc*, mips*, ppc and arm64 again > - add missing sparc, alpha and i386 abi compat for struct __sanitizer_addrinfo > - avoid linux includes on arm64 > - avoid multiply defined __ubsan_handle_cfi_bad_type when UBSAN_CAN_USE_CXXABI > isn't defined, and, undefine it > - bad_array_length.cc and bad_array_new.cc lose special build rules > - regen arm64 mknative > > ubsan_handlers_cxx.cc should be detached from the build (unless we will adapt llvm libc++ abi). signature.asc Description: OpenPGP digital signature
re: CVS commit: src/external/gpl3/gcc/usr.bin/gcc/arch/aarch64
"Nick Hudson" writes: > Module Name: src > Committed By: skrll > Date: Wed Oct 2 10:34:48 UTC 2019 > > Modified Files: > src/external/gpl3/gcc/usr.bin/gcc/arch/aarch64: defs.mk > > Log Message: > Remove garbage. Maybe something is wrong with mknative or mrg's script? thanks. this happens when mknative is run a second time, not sure why it's started happening yet. appears to be mknative not me. btw, if you were hitting this, you need to clean your tree because this subdir shouldn't be used currently by anyone -- it's now got gcc 8 bits, and the default for everyone is still gcc 7. .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc, vax crashes
For future reference, proably by me:
Reproducer for the crash without the local diff:
#!/bin/sh
cat << EOF > oacc.i
int a, b;
int e() {
short *c = 0;
char d = c[a + 1];
b = d;
a += 2;
}
EOF
vax--netbsdelf-gcc -O2 -c oacc.i
This hits an assertion:
emit-rtl.c:2310 gcc_assert (memory_address_addr_space_p (mode, addr, as));
This points to vax code, vax_legitimate_address_p.
This function might not handle some addressing modes, possibly one of
these two:
c: b0 40 9f 02 movw *0x2[r0],r1
c: 98 40 a0 02 cvtbl 0x2(r0)[r0],15
Re: CVS commit: src/external/gpl3/gcc/dist/libstdc++-v3
Hi, Christos Zoulas writes: > Thank you. What's left now is to re-run mknative to regenerate the defs.mk > file for libstdc++. > mrg@ is going to do it for all archs at once because it will require an > UPDATING entry to > mention to clean in /usr/src/external/gpl3/lib/libstdc++. Once that is done > and all the archs > are building, I will issue pull-ups for -9. Thanks for your explanation. I am waiting the fix. And I am happy to hear the fix will be included in netbsd-9. > Best, > > christos > >> On Aug 1, 2019, at 3:30 AM, Ryo ONODERA wrote: >> >> Hi, >> >> "Christos Zoulas" writes: >> >>> Module Name:src >>> Committed By: christos >>> Date: Wed Jul 31 16:40:26 UTC 2019 >>> >>> Modified Files: >>> src/external/gpl3/gcc/dist/libstdc++-v3: configure >>> >>> Log Message: >>> Manually patch the locale configuration to use the dragonfly code instead >>> of generic. >>> >>> >>> To generate a diff of this commit: >>> cvs rdiff -u -r1.11 -r1.12 src/external/gpl3/gcc/dist/libstdc++-v3/configure >>> >>> Please note that diffs are not public domain; they are subject to the >>> copyright notices on the relevant files. >> >> Some other changes in your g++locale.diff are required to >> enable DragonFly code. >> Are there any plans to commit the others? >> >> Thanks for your great works. >> >> -- >> Ryo ONODERA // r...@tetera.org >> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 > -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/external/gpl3/gcc/dist/libstdc++-v3
Hi, "Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Wed Jul 31 16:40:26 UTC 2019 > > Modified Files: > src/external/gpl3/gcc/dist/libstdc++-v3: configure > > Log Message: > Manually patch the locale configuration to use the dragonfly code instead > of generic. > > > To generate a diff of this commit: > cvs rdiff -u -r1.11 -r1.12 src/external/gpl3/gcc/dist/libstdc++-v3/configure > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. Some other changes in your g++locale.diff are required to enable DragonFly code. Are there any plans to commit the others? Thanks for your great works. -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
On 01.06.2019 21:04, Christos Zoulas wrote: > On Jun 1, 8:48pm, n...@gmx.com (Kamil Rytarowski) wrote: > -- Subject: Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan > > | There is some overlap, but not full. > > I understand. > > | https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/rtl/tsan_rt= > | l_amd64.S > | > | Each call of this code was verified and it passed regression suite. > | > | There is also need to handle NetBSD specific renaming of symbols in this > | file and in .c file. > > I also said that the NetBSD symbols are not handled. Newer gcc will fix it. > I just wanted to make it compile. > > christos > I see, thank you! I'm doing it in the way that code flows with new upstream versions into the basesystem. Cherry picking TSan support shouldn't be that difficult probably. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
On Jun 1, 8:48pm, n...@gmx.com (Kamil Rytarowski) wrote: -- Subject: Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan | There is some overlap, but not full. I understand. | https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/rtl/tsan_rt= | l_amd64.S | | Each call of this code was verified and it passed regression suite. | | There is also need to handle NetBSD specific renaming of symbols in this | file and in .c file. I also said that the NetBSD symbols are not handled. Newer gcc will fix it. I just wanted to make it compile. christos
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
On 01.06.2019 20:38, Christos Zoulas wrote: > I just checked and the offsets are correct (we are the same as FreeBSD). > We are missing support for the the names of the functions __setjmp14 etc. > > Thanks, > There is some overlap, but not full. https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/rtl/tsan_rtl_amd64.S Each call of this code was verified and it passed regression suite. There is also need to handle NetBSD specific renaming of symbols in this .S file and in .c file. > christos > >> On Jun 1, 2019, at 1:52 PM, Kamil Rytarowski wrote: >> >> On 01.06.2019 19:22, Christos Zoulas wrote: >>> Module Name:src >>> Committed By: christos >>> Date: Sat Jun 1 17:22:58 UTC 2019 >>> >>> Modified Files: >>> src/external/gpl3/gcc/dist/libsanitizer/tsan: tsan_rtl_amd64.S >>> >>> Log Message: >>> Do as FreeBSD does now (I have not checked that the offsets are correct) >>> >> >> These values differ on NetBSD. >> >> There is upstreamed support into upstream repository here: >> >> https://github.com/llvm-mirror/compiler-rt/tree/master/lib/tsan/rtl >> >> Please grep for NetBSD specific code. We will get it with GCC9, maybe >> GCC8.. but I would need to check. >> >> > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
I just checked and the offsets are correct (we are the same as FreeBSD). We are missing support for the the names of the functions __setjmp14 etc. Thanks, christos > On Jun 1, 2019, at 1:52 PM, Kamil Rytarowski wrote: > > On 01.06.2019 19:22, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sat Jun 1 17:22:58 UTC 2019 >> >> Modified Files: >> src/external/gpl3/gcc/dist/libsanitizer/tsan: tsan_rtl_amd64.S >> >> Log Message: >> Do as FreeBSD does now (I have not checked that the offsets are correct) >> > > These values differ on NetBSD. > > There is upstreamed support into upstream repository here: > > https://github.com/llvm-mirror/compiler-rt/tree/master/lib/tsan/rtl > > Please grep for NetBSD specific code. We will get it with GCC9, maybe > GCC8.. but I would need to check. > >
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
On 01.06.2019 19:22, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Jun 1 17:22:58 UTC 2019 > > Modified Files: > src/external/gpl3/gcc/dist/libsanitizer/tsan: tsan_rtl_amd64.S > > Log Message: > Do as FreeBSD does now (I have not checked that the offsets are correct) > These values differ on NetBSD. There is upstreamed support into upstream repository here: https://github.com/llvm-mirror/compiler-rt/tree/master/lib/tsan/rtl Please grep for NetBSD specific code. We will get it with GCC9, maybe GCC8.. but I would need to check. signature.asc Description: OpenPGP digital signature
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/lib
> UBSan can be combined with ASan and TSan. > > The way to go is to link UBSan into ASan/TSan/etc. > > I'm doing this in LLVM ones here: > http://netbsd.org/~kamil/llvm/llvm-sanitizers-patch1.txt > > Additionally ASan should link LSan code. > > We apparently want more tests in ATF verifying *San + UBSan used > concurrently. the code in GCC 7 explicitly sets the CAN_SANITIZE_UB how i've done it in our reach over makefiles. i'm at first only interested in making things work as they are expected to upstream (which in this case, is gcc, not their upstream :-). you or someone else are welcome to advance this state again, but i'm unlikely to look at it. thanks. .mrg.
Re: CVS commit: src/external/gpl3/gcc/lib
On 08.02.2019 23:06, matthew green wrote: > Module Name: src > Committed By: mrg > Date: Fri Feb 8 22:06:12 UTC 2019 > > Modified Files: > src/external/gpl3/gcc/lib/libasan: Makefile > src/external/gpl3/gcc/lib/libtsan: Makefile > src/external/gpl3/gcc/lib/libubsan: Makefile > > Log Message: > define CAN_SANITIZE_UB properly: libasan and libtsan need to not > have it set, libubsan needs to have it set. > > fixes almost all the new atf failures from GCC 7 switch. > > UBSan can be combined with ASan and TSan. The way to go is to link UBSan into ASan/TSan/etc. I'm doing this in LLVM ones here: http://netbsd.org/~kamil/llvm/llvm-sanitizers-patch1.txt Additionally ASan should link LSan code. We apparently want more tests in ATF verifying *San + UBSan used concurrently. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc/dist/libiberty
In article <20180715143153.gb28...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Sat, Jul 14, 2018 at 07:41:43PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jul 14 23:41:43 UTC 2018
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/libiberty: alloca.c
>>
>> Log Message:
>> clang does not like auto in c++
>
>This is not about Clang at all. auto has a quite different meaning with
>C++11 and that's even the default for newer GCC...
Yes, I totally understand that, but this is about "compiling c
files with c++" and the mode that clang chooses is different that
gcc's {how it interprets things, and what it warns and errors about)
is different. Removing the auto from the c file is harmless and makes
it compile under c++ with clang.
christos
Re: CVS commit: src/external/gpl3/gcc/dist/libiberty
On Sat, Jul 14, 2018 at 07:41:43PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Jul 14 23:41:43 UTC 2018 > > Modified Files: > src/external/gpl3/gcc/dist/libiberty: alloca.c > > Log Message: > clang does not like auto in c++ This is not about Clang at all. auto has a quite different meaning with C++11 and that's even the default for newer GCC... Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer
On 05.02.2018 23:04, matthew green wrote: > Module Name: src > Committed By: mrg > Date: Mon Feb 5 22:04:54 UTC 2018 > > Modified Files: > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: > sanitizer_linux.cc sanitizer_platform_limits_posix.cc > src/external/gpl3/gcc/dist/libsanitizer/ubsan: ubsan_platform.h > > Log Message: > - enable powerpc and arm support. > - port GetPcSpBp() to netbsd/powerpc* and netbsd/arm. > > Upstream for the sanitizers is located in LLVM compiler-rt/lib (it's equivalent to libsanitier in GCC with added wrappers for GCC). https://github.com/llvm-mirror/compiler-rt 8snapshot contains a decent part of the upstreamed NetBSD work (at least ASan, UBSan, partial TSan). I think that we should upgrade libsanitizer to 8snapshot as-is, instead of repeating the porting effort for 6.x. Or even better upgrade to HEAD from LLVM directly (TSan, MSan + other fixes). I will pickup the !amd64 patches added here and upstream to LLVM directly. signature.asc Description: OpenPGP digital signature
re: CVS commit: src/external/gpl3/gcc/usr.bin
> Log Message: > pull across from gcc.old: > >https://bugzilla.eng.vmware.com/show_bug.cgi?id=1703878#c118 oops. fixed to read "ensure version.c gets rebuilt properly."
re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common
On Sep 22, 4:02pm, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer | sorry to bug you again, but... ;) | | > Modified Files: | > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: | > sanitizer_platform_limits_posix.h | > | > Log Message: | > Check the NetBSD version | | ! # ifdef __NetBSD__ | | hmmm, shouldn't that be SANITZIER_NETBSD or whatever it is? Could be... I've changed it. christos
re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common
sorry to bug you again, but... ;) > Modified Files: > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: > sanitizer_platform_limits_posix.h > > Log Message: > Check the NetBSD version ! # ifdef __NetBSD__ hmmm, shouldn't that be SANITZIER_NETBSD or whatever it is?
re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Wed Sep 21 19:18:01 UTC 2016 > > Modified Files: > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: > sanitizer_platform_limits_posix.h > > Log Message: > add new field + #ifdef __NetBSD__ + unsigned int ifa_addrflags; + #endif thanks for cleaning up :-) can you make this version specific so that we can upstream this change? the above only works on todays netbsd. thanks. .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common
On 2016/06/09 23:37, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Thu Jun 9 14:37:06 UTC 2016
Modified Files:
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
sanitizer_linux.cc sanitizer_syscall_generic.inc
Log Message:
Fix syscall argument passing from Ryn Okuyama (with minor changes; hope I did
not make it worse :-)
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 \
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc
cvs rdiff -u -r1.2 -r1.3 \
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Thank you very much for refinement and commit my patch. Let me add
few comments:
* internal_ptrace()
As usage of ptrace(2) is quite different for Linux and us, we need
additional work to get it working. At this moment, this function is
used only within "#if SANITIZER_LINUX && defined(__x86_64__)" block
in sanitizer_stoptheworld_linux_libcdep.cc. This is why I disabled
it in my previous patch. I've added a brief comment.
* internal_wait4()
The last argument of wait4(2) should be NULL, not 0. This may
cause troubles for LP64.
* internal_getdents()
Sorry, my previous patch for this function was completely wrong.
But your version is also incomplete:
- structure dirent is different for Linux and us; we need to
declare linux_dirent in the same way as our native dirent.
- The last argument of getdents(2) should be size_t (aka uptr),
not u_int.
* sanitizer_syscall_generic.inc
Sorry, this is also my careless mistake. Two #if blocks should
be combined to avoid possible redefinition of internal_syscall.
Thanks,
Rin
---
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc.orig
2016-06-10 06:14:51.159752456 +0900
+++ src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc
2016-06-10 09:16:19.561985484 +0900
@@ -56,6 +56,7 @@
extern char **environ; // provided by crt1
#endif // SANITIZER_FREEBSD
#if SANITIZER_NETBSD
+#include // for NAME_MAX
#include
extern char **environ; // provided by crt1
#endif // SANITIZER_NETBSD
@@ -491,6 +492,17 @@
}
// - sanitizer_linux.h
+#if SANITIZER_NETBSD
+// struct dirent is different for Linux and us. At this moment, we use only
+// d_fileno (Linux call this d_ino), d_reclen, and d_name.
+struct linux_dirent {
+ u64 d_ino; // d_fileno
+ u16 d_reclen;
+ u16 d_namlen; // not used
+ u8 d_type;// not used
+ char d_name[NAME_MAX + 1];
+};
+#else
// The actual size of this structure is specified by d_reclen.
// Note that getdents64 uses a different structure format. We only provide the
// 32-bit syscall here.
@@ -505,10 +517,18 @@
unsigned short d_reclen;
char d_name[256];
};
+#endif
// Syscall wrappers.
uptr internal_ptrace(int request, int pid, void *addr, void *data) {
#if SANITIZER_NETBSD
+// XXX We need additional work for ptrace:
+// - for request, we use PT_FOO whereas Linux uses PTRACE_FOO
+// - data is int for us, but void * for Linux
+// - Linux sometimes uses data in the case where we use addr instead
+// At this moment, this function is used only within
+// "#if SANITIZER_LINUX && defined(__x86_64__)" block in
+// sanitizer_stoptheworld_linux_libcdep.cc.
return internal_syscall_ptr(SYSCALL(ptrace), request, pid, (uptr)addr,
(uptr)data);
#else
@@ -518,8 +538,13 @@
}
uptr internal_waitpid(int pid, int *status, int options) {
+#if SANITIZER_NETBSD
+ return internal_syscall(SYSCALL(wait4), pid, status, options,
+ NULL /* rusage */);
+#else
return internal_syscall(SYSCALL(wait4), pid, (uptr)status, options,
0 /* rusage */);
+#endif
}
uptr internal_getpid() {
@@ -531,7 +556,9 @@
}
uptr internal_getdents(fd_t fd, struct linux_dirent *dirp, unsigned int count) {
-#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
+#if SANITIZER_NETBSD
+ return internal_syscall(SYSCALL(getdents), fd, dirp, (uptr)count);
+#elif SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
return internal_syscall(SYSCALL(getdents64), fd, (uptr)dirp, count);
#else
return internal_syscall(SYSCALL(getdents), fd, (uptr)dirp, count);
---
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc.orig
2016-06-10 07:09:34.310819833 +0900
+++
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc
2016-06-10 07:09:51.201896163 +0900
@@ -38,9 +38,7 @@
# else
# define internal_syscall_ptrsyscall
# endif
-#endif
-
-#if (SANITIZER_FREEBSD && defined(__x86_64__))
+#elif (SANITIZER_FREEBSD && defined(__x86_64__))
# define internal_syscall __syscall
#
Re: CVS commit: src/external/gpl3/gcc/dist/gcc
On Wed, Mar 23, 2016 at 08:52:43AM -0400, Christos Zoulas wrote: > 3) Removed definitions of EH_RETURN_STACKADJ_RTX and STARTING_FRAME_OFFSET > from gcc/config/vax/elf.h. It's not necessary to remember the stack > adjustment or to waste four bytes on every stack frame for a value > that's not needed. Also remove the suspicious changes in > gcc/config/vax/vax.md to the definitions of call_pop and call_value > regarding DW_CFA_GNU_args_size and EH unwinding. I reverted to the > previous versions from an older version of GCC, adding a few useful > comments that had been removed. The latter part seems quite wrong as the VAX calling convention generally requires reading the argument size from the stack... Joerg
re: CVS commit: src/external/gpl3/gcc
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Thu Mar 17 00:56:05 UTC 2016 > > Modified Files: > src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64: c++config.h > src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64: auto-host.h configargs.h > src/external/gpl3/gcc/usr.bin/libcpp/arch/x86_64: config.h > Added Files: > src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64: insn-modes.h > > Log Message: > regen amd64 this looks very broken: -#define _GLIBCXX_HAVE_ACOSF 1 +/* #undef _GLIBCXX_HAVE_ACOSF */ .. -#define _GLIBCXX_HAVE_CEILF 1 +/* #undef _GLIBCXX_HAVE_CEILF */ .. i guess i forgot to commit insn-modes.h. .mrg.
Re: CVS commit: src/external/gpl3/gcc/lib/libstdc++-v3
In article pine.neb.4.64.1405301548250.17...@screamer.whooppee.com, Paul Goyette p...@whooppee.com wrote: Joerg Sonnenberger writes: IMO it is wrong to force every C++ program to link against libpthread, which is not that cheap. i'd buy that -- except that libstdc++ now references pthread_create() directly, and i don't know how to deal with that. See how I did it for libc++? Make the reference weak and raise an error for those things only that want to create a threead. Just curious - is this going to be changed? I'll take a look at it. christos
Re: CVS commit: src/external/gpl3/gcc/lib/libstdc++-v3
Joerg Sonnenberger writes: IMO it is wrong to force every C++ program to link against libpthread, which is not that cheap. i'd buy that -- except that libstdc++ now references pthread_create() directly, and i don't know how to deal with that. See how I did it for libc++? Make the reference weak and raise an error for those things only that want to create a threead. Just curious - is this going to be changed? - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
re: CVS commit: src/external/gpl3/gcc/lib/libstdc++-v3
Paul Goyette writes: Joerg Sonnenberger writes: IMO it is wrong to force every C++ program to link against libpthread, which is not that cheap. i'd buy that -- except that libstdc++ now references pthread_create() directly, and i don't know how to deal with that. See how I did it for libc++? Make the reference weak and raise an error for those things only that want to create a threead. Just curious - is this going to be changed? that's the plan, but i haven't even begun to look at it. if someone else wants to do it, please go ahead. i don't expect to find time anytime soon... .mrg.
Re: CVS commit: src/external/gpl3/gcc
On Wed, May 28, 2014 at 09:09:40AM +, Matthew Green wrote: Module Name: src Committed By: mrg Date: Wed May 28 09:09:39 UTC 2014 Modified Files: src/external/gpl3/gcc/lib/libstdc++-v3/arch/alpha: c++config.h config.h [...] src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64: configargs.h Log Message: re-run mknative-gcc after threading fixes by skrll and myself. I get build failures on NetBSD/amd64 which seem to be related to threading: dependall === gnu/usr.bin/groff/src/devices/grodvi # link grodvi/grodvi /src/tools/bin/x86_64--netbsd-c++ --sysroot=/export/scratch/tron/obj/destdir.amd64 -o grodvi dvi.o -Wl,-rpath-link,/export/scratch/tron/obj/destdir.amd64/lib -L=/lib /export/scratch/tron/obj/gnu/usr.bin/groff/src/libs/libdriver/libdriver.a /export/scratch/tron/obj/gnu/usr.bin/groff/src/libs/libgroff/libgroff.a -lm /export/scratch/tron/obj/destdir.amd64/usr/lib/libstdc++.so: undefined reference to `std::__exception_ptr::exception_ptr::exception_ptr()'/export/scratch/tron/obj/destdir.amd64/usr/lib/libstdc++.so: undefined reference to `pthread_create' /export/scratch/tron/obj/destdir.amd64/usr/lib/libstdc++.so: undefined reference to `std::__exception_ptr::exception_ptr::~exception_ptr()'collect2: error: ld returned 1 exit status *** Failed target: grodvi *** Failed command: /src/tools/bin/x86_64--netbsd-c++ --sysroot=/export/scratch/tron/obj/destdir.amd64 -o grodvi dvi.o -Wl,-rpath-link,/export/scratch/tron/obj/destdir.amd64/lib -L=/lib /export/scratch/tron/obj/gnu/usr.bin/groff/src/libs/libdriver/libdriver.a /export/scratch/tron/obj/gnu/usr.bin/groff/src/libs/libgroff/libgroff.a -lm *** Error code 1 Stop. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: CVS commit: src/external/gpl3/gcc
On Wed, May 28, 2014 at 02:12:40PM +0100, Matthias Scheler wrote: On Wed, May 28, 2014 at 09:09:40AM +, Matthew Green wrote: Module Name:src Committed By: mrg Date: Wed May 28 09:09:39 UTC 2014 Modified Files: src/external/gpl3/gcc/lib/libstdc++-v3/arch/alpha: c++config.h config.h [...] src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64: configargs.h Log Message: re-run mknative-gcc after threading fixes by skrll and myself. I get build failures on NetBSD/amd64 which seem to be related to threading: The automated builds have reported the same failure in the meantime: http://mail-index.netbsd.org/current-users/2014/05/28/msg024980.html Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: CVS commit: src/external/gpl3/gcc/lib/libstdc++-v3
On Wed, May 28, 2014 at 04:41:06PM +, matthew green wrote: Module Name: src Committed By: mrg Date: Wed May 28 16:41:06 UTC 2014 Modified Files: src/external/gpl3/gcc/lib/libstdc++-v3: Makefile Log Message: add -pthread to compiler/linker flags. fixes 1/3 of the link issues. IMO it is wrong to force every C++ program to link against libpthread, which is not that cheap. Joerg
re: CVS commit: src/external/gpl3/gcc/lib/libstdc++-v3
Joerg Sonnenberger writes: On Wed, May 28, 2014 at 04:41:06PM +, matthew green wrote: Module Name:src Committed By: mrg Date: Wed May 28 16:41:06 UTC 2014 Modified Files: src/external/gpl3/gcc/lib/libstdc++-v3: Makefile Log Message: add -pthread to compiler/linker flags. fixes 1/3 of the link issues. IMO it is wrong to force every C++ program to link against libpthread, which is not that cheap. i'd buy that -- except that libstdc++ now references pthread_create() directly, and i don't know how to deal with that. .mrg.
Re: CVS commit: src/external/gpl3/gcc/lib/libstdc++-v3
On Thu, May 29, 2014 at 07:56:31AM +1000, matthew green wrote: Joerg Sonnenberger writes: On Wed, May 28, 2014 at 04:41:06PM +, matthew green wrote: Module Name: src Committed By: mrg Date: Wed May 28 16:41:06 UTC 2014 Modified Files: src/external/gpl3/gcc/lib/libstdc++-v3: Makefile Log Message: add -pthread to compiler/linker flags. fixes 1/3 of the link issues. IMO it is wrong to force every C++ program to link against libpthread, which is not that cheap. i'd buy that -- except that libstdc++ now references pthread_create() directly, and i don't know how to deal with that. See how I did it for libc++? Make the reference weak and raise an error for those things only that want to create a threead. Joerg
Re: CVS commit: src/external/gpl3/gcc
On 26.02.14 11:50, matthew green wrote:
Module Name: src
Committed By: mrg
Date: Wed Feb 26 10:50:23 UTC 2014
Added Files:
src/external/gpl3/gcc: gcc2gcc.old
Log Message:
script to copy gcc to gcc.old, ready for importing.
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/external/gpl3/gcc/gcc2gcc.old
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Added files:
Index: src/external/gpl3/gcc/gcc2gcc.old
diff -u /dev/null src/external/gpl3/gcc/gcc2gcc.old:1.1
--- /dev/null Wed Feb 26 10:50:23 2014
+++ src/external/gpl3/gcc/gcc2gcc.old Wed Feb 26 10:50:23 2014
@@ -0,0 +1,63 @@
+#! /bin/sh
+#
+#$NetBSD: gcc2gcc.old,v 1.1 2014/02/26 10:50:23 mrg Exp $
+
+# run it like eg:
+#
+# % ./gcc2gcc.old /usr/src/external/gpl3/gcc /home/import/gcc
+
+doit=echo
+doit=
Isn't that a nop?
+
+progname=$(basename $0)
+
+usage() {
+ echo Usage: $progname src/external/gpl3/gcc copy-to-dir 12
+ edho Note that copy-to-dir must not exist. 12
s/edho/echo/
+ exit 1
+}
+
+#set -x
+set -e
+
+srcdir=$1
+destdir=$2
+
+if [ -z $srcdir -o -z $destdir ]; then
+ usage
+fi
+
+if [ ! -d $srcdir ]; then
+ echo srcdir '$srcdir' is not a directory 12
+ usage
+fi
+if [ -e $destdir ]; then
+ echo destdir '$destdir' is something 12
+ ls -ld $destdir
+ usage
+fi
+
+# Assumes that ../gcc/. == .
+cd $srcdir/..
+if [ ! -d gcc ]; then
+ echo $srcdir/../gcc doesn't exist. 12
+ usage
+fi
+
+echo Copying files to $destdir...
+$doit pax -rwpp gcc $destdir
+
+
+# clean the copy
+echo Cleaning CVS turds and ChangeLogs
+$doit find $destdir -name .CVS -exec rm -rf {} +
+$doit find $destdir -name CVS -exec rm -rf {} +
+$doit find $destdir -name ChangeLog* -exec rm -f {} +
+$doit rm -f $destdir/gcc2netbsd $destdir/gcc2gcc.old
+
+date=$(date +%Y%m%M-%H%M)
I think, it isn't necessary to invoke a subshell.
date=`date +%Y%m%M-%H%M` is enough.
Christoph
+echo GCC copied to gcc.old. use these commands to import:
+echo cd $destdir/gcc
+echo cvs import src/external/gpl3/gcc.old NetBSD src-external-gpl3-gcc-$date
+
+exit 0
Re: CVS commit: src/external/gpl3/gcc
Christoph Egger christoph_eg...@gmx.de wrote On 26.02.14 11:50, matthew green wrote: +date=$(date +%Y%m%M-%H%M) I think, it isn't necessary to invoke a subshell. date=`date +%Y%m%M-%H%M` is enough. date +%Y%m%d-%H%M ? -- Takeshi Nakayama
Re: CVS commit: src/external/gpl3/gcc
On Wed, Feb 26, 2014 at 11:58:18AM +0100, Christoph Egger wrote: +date=$(date +%Y%m%M-%H%M) I think, it isn't necessary to invoke a subshell. date=`date +%Y%m%M-%H%M` is enough. Both forms involve a subshell, the only difference between $() and `` is quoting. Joerg
re: CVS commit: src/external/gpl3/gcc
+date=$(date +%Y%m%M-%H%M) I think, it isn't necessary to invoke a subshell. date=`date +%Y%m%M-%H%M` is enough. date +%Y%m%d-%H%M ? ah, thanks.
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 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 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
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 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
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 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
(2012/09/16 16:26), SAITOH Masanobu wrote: Module Name: src Committed By: msaitoh Date: Sun Sep 16 07:26:31 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc: ChangeLog src/external/gpl3/gcc/dist/gcc/config/arm: arm.md Log Message: Fix gcc bugid 51408 for arm. To generate a diff of this commit: cvs rdiff -u -r1.3 -r1.4 src/external/gpl3/gcc/dist/gcc/ChangeLog cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/gcc/config/arm/arm.md Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Sorry, this change fixes PR#46972. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
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
Re: CVS commit: src/external/gpl3/gcc/dist
Is someone working on submitting (the interesting ones of) these upstream? Now that the patches are fresh is probably the easiest time... Thomas On Tue, Jun 21, 2011 at 02:41:40AM +, matthew green wrote: Module Name: src Committed By: mrg Date: Tue Jun 21 02:41:39 UTC 2011 Modified Files: src/external/gpl3/gcc/dist: configure configure.ac src/external/gpl3/gcc/dist/gcc: Makefile.in c-opts.c c.opt cfgexpand.c config.gcc configure configure.ac gcc.c gcc.h genemit.c genmultilib genrecog.c hwint.h libgcc2.c tree-cfg.c src/external/gpl3/gcc/dist/gcc/config: netbsd-elf.h netbsd.h src/external/gpl3/gcc/dist/gcc/config/arm: t-arm src/external/gpl3/gcc/dist/gcc/config/m68k: m68k.md src/external/gpl3/gcc/dist/gcc/config/mips: netbsd.h src/external/gpl3/gcc/dist/gcc/config/pa: milli64.S pa.c pa.h src/external/gpl3/gcc/dist/gcc/config/rs6000: netbsd.h rs6000.c sysv4.h t-netbsd src/external/gpl3/gcc/dist/gcc/config/sh: t-netbsd src/external/gpl3/gcc/dist/gcc/config/sparc: netbsd-elf.h t-netbsd64 src/external/gpl3/gcc/dist/gcc/doc: cpp.texi cppenv.texi cppopts.texi gcov.texi invoke.texi src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h src/external/gpl3/gcc/dist/libcpp: Makefile.in files.c init.c internal.h lex.c macro.c src/external/gpl3/gcc/dist/libcpp/include: cpplib.h src/external/gpl3/gcc/dist/libiberty: floatformat.c strerror.c src/external/gpl3/gcc/dist/libobjc: hash.c src/external/gpl3/gcc/dist/libstdc++-v3: crossconfig.m4 src/external/gpl3/gcc/dist/libstdc++-v3/config/os/bsd/netbsd: ctype_base.h Log Message: merge forward our changes into the GCC 4.5.3 tree. mostly from chuq. To generate a diff of this commit: cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/configure \ src/external/gpl3/gcc/dist/configure.ac cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/gcc/Makefile.in \ src/external/gpl3/gcc/dist/gcc/c-opts.c \ src/external/gpl3/gcc/dist/gcc/c.opt \ src/external/gpl3/gcc/dist/gcc/cfgexpand.c \ src/external/gpl3/gcc/dist/gcc/config.gcc \ src/external/gpl3/gcc/dist/gcc/configure \ src/external/gpl3/gcc/dist/gcc/configure.ac \ src/external/gpl3/gcc/dist/gcc/gcc.c src/external/gpl3/gcc/dist/gcc/gcc.h \ src/external/gpl3/gcc/dist/gcc/genemit.c \ src/external/gpl3/gcc/dist/gcc/genmultilib \ src/external/gpl3/gcc/dist/gcc/genrecog.c \ src/external/gpl3/gcc/dist/gcc/hwint.h \ src/external/gpl3/gcc/dist/gcc/libgcc2.c \ src/external/gpl3/gcc/dist/gcc/tree-cfg.c cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/netbsd-elf.h \ src/external/gpl3/gcc/dist/gcc/config/netbsd.h cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/gcc/config/arm/t-arm cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/mips/netbsd.h cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/pa/milli64.S \ src/external/gpl3/gcc/dist/gcc/config/pa/pa.c \ src/external/gpl3/gcc/dist/gcc/config/pa/pa.h cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/rs6000/netbsd.h \ src/external/gpl3/gcc/dist/gcc/config/rs6000/rs6000.c \ src/external/gpl3/gcc/dist/gcc/config/rs6000/sysv4.h \ src/external/gpl3/gcc/dist/gcc/config/rs6000/t-netbsd cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/sh/t-netbsd cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/sparc/netbsd-elf.h \ src/external/gpl3/gcc/dist/gcc/config/sparc/t-netbsd64 cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/gcc/doc/cpp.texi \ src/external/gpl3/gcc/dist/gcc/doc/cppenv.texi \ src/external/gpl3/gcc/dist/gcc/doc/cppopts.texi \ src/external/gpl3/gcc/dist/gcc/doc/gcov.texi \ src/external/gpl3/gcc/dist/gcc/doc/invoke.texi cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/gcc/ginclude/stddef.h cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/libcpp/Makefile.in \ src/external/gpl3/gcc/dist/libcpp/files.c \ src/external/gpl3/gcc/dist/libcpp/init.c \ src/external/gpl3/gcc/dist/libcpp/internal.h \ src/external/gpl3/gcc/dist/libcpp/lex.c \ src/external/gpl3/gcc/dist/libcpp/macro.c cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/libcpp/include/cpplib.h cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/libiberty/floatformat.c \ src/external/gpl3/gcc/dist/libiberty/strerror.c cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/libobjc/hash.c cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/libstdc++-v3/crossconfig.m4 cvs rdiff -u -r1.1.1.1 -r1.2 \
