On Wed, 2023-11-08 00:04:52 +1100, Kalvis Duckmanton <kalvisd%gmail.com@localhost> wrote:
> On 7/11/23 00:58, Hans Rosenfeld wrote:
> > has anyone already succeeded in doing a native build of -10 on the VAX?
> >
> > I'm stuck at the tools build, with gcc failing in a way that I don't
> > really understand:
> >
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c: In instantiation of 'const pass_data {anonymous}::pass_sancov<false>::data':
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c:307:55: required from '{anonymous}::pass_sancov<O0>::pass_sancov(gcc::context*) [with bool O0 = false]'
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c:345:38: required from here
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c:328:17: error: 'constinit' variable '{anonymous}::pass_sancov<false>::data' does not have a constant initializer
> > 328 | const pass_data pass_sancov<O0>::data = {
> > | ^~~~~~~~~~~~~~~
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c: In instantiation of 'const pass_data {anonymous}::pass_sancov<true>::data':
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c:307:55: required from '{anonymous}::pass_sancov<O0>::pass_sancov(gcc::context*) [with bool O0 = true]'
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c:351:37: required from here
> > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/sancov.c:328:17: error: 'constinit' variable '{anonymous}::pass_sancov<true>::data' does not have a constant initializer
> >
> > The code in question looks sane, and so does the preprocessor
> > output. The same code built correctly when cross-built on amd64 (on
> > illumos, though).
> >
> > I assume this has once worked on -current? Perhaps there something got
> > inadvertently broken in the pullups to -10?
>
> Hmm. I'm not entirely sure but I *think* this is a manifestation of GCC bug
> c++/105491. Native GCC 10 for VAX from -current also fails in the same way,
> but the GCC 10 cross-compiler from -current (on amd64 on Linux), can compile
> the same code without issue. It's weird. I'd have expected the
> cross-compiler to also fail. For what it's worth, the (patched) native GCC
> 12.2 that I've built from pkgsrc can compile sancov.c from GCC 10 without
> complaint. (Bug 105491 is fixed in GCC 12.2 and later.)
>
> I have an inelegant workaround for GCC 10 but it needs some more testing.
Building -current on Linux ("tools" and "libs") with -V HAVE_GCC=12, I
get this right now:
# compile libcrypt/blake2b.o
/opt/build-netbsd.3673118/tools/bin/vax--netbsdelf-gcc -O2 -fdebug-prefix-map=\$DESTDIR= -fmacro-prefix-map=\$DESTDIR= -fdebug-prefix-map=\$NETBSDSRCDIR=/usr/src -fmacro-prefix-map=\$NETBSDSRCDIR=/usr/src -fdebug-prefix-map=\$X11SRCDIR=/usr/xsrc -fmacro-prefix-map=\$X11SRCDIR=/usr/xsrc -fdebug-regex-map='/usr/src/(.*)/obj$=/usr/obj/\1' -fdebug-regex-map='/usr/src/(.*)/obj/(.*)=/usr/obj/\1/\2' -fdebug-regex-map='/usr/src/(.*)/obj\..*=/usr/obj/\1' -fdebug-regex-map='/usr/src/(.*)/obj\..*/(.*)=/usr/obj/\1/\2' -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror -fstack-protector -Wstack-protector --param ssp-buffer-size=1 --sysroot=/opt/build-netbsd.3673118/dest -include /opt/build-netbsd.3673118/src/lib/libcrypt/namespace.h -DHAVE_ARGON2 -DARGON2_NO_THREADS -I/opt/build-netbsd.3673118/src/external/apache2/argon2/dist/phc-winner-argon2/include -Wp,-iremap,/opt/build-netbsd.3673118/dest: -Wp,-fno-canonical-system-headers -Wp,-iremap,/opt/build-netbsd.3673118/src:/usr/src -Wp,-iremap,/usr/xsrc:/usr/xsrc -D_FORTIFY_SOURCE=2 -c -fvisibility=hidden /opt/build-netbsd.3673118/src/external/apache2/argon2/dist/phc-winner-argon2/src/blake2/blake2b.c -o blake2b.o
during RTL pass: postreload
/opt/build-netbsd.3673118/src/external/apache2/argon2/dist/phc-winner-argon2/src/blake2/blake2b.c: In function 'blake2b_compress':
/opt/build-netbsd.3673118/src/external/apache2/argon2/dist/phc-winner-argon2/src/blake2/blake2b.c:222:1: internal compiler error: in cselib_invalidate_regno, at cselib.cc:2490
222 | }
| ^
0x7fda31ff9189 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fda31ff9244 __libc_start_main_impl
../csu/libc-start.c:381
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://www.NetBSD.org/support/send-pr.html> for instructions.
*** Failed target: blake2b.o
Are there patches on the fly to catch this? Or is this new?
In any way, it's really REALLY good news to see so much stuff
happening for VAX these days!
MfG, JBG
--
Attachment:
signature.asc
Description: PGP signature