From Newsgroup: alt.os.linux.slackware

I have a sticky problem here: two machines, one Ryzen 5, one 9. decnet3
(my package I posted before on here, actually) builds on the 5 but not
on the 9. On the 9, GCC bombs out with in internal compiler error. I'm
seeing the same thing with cool-retro-term. Everything else I've tried
to build so far has succeeded, so I know the compiler works. decnet3 nor cool-retro-term are a part of core Slackware but GCC is. Slackware
Current as of a few days ago, and both GCC versions are the same.

Any idea where to go with this? It's not the dev's code, because it
works on the 5. The only thing I can come up with is maybe it's due to
the CPU, a Ryzen 9 9950X. binutils are the same on both machines. Code
was pulled from github just now on both machines.

make[1]: Entering directory '/usr/src/decnet3/LinuxDECnet/dnprogs/libdap'
g++ -pipe -fdollars-in-identifiers -fsigned-char -Wall -Wno-unused -Wno-uninitialized -I../libdap -I../include -DVERSION=\"3.27\" -D_XOPEN_SOURCE -D_DEFAULT_SOURCE -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSHADOW_PWD -DDNETUSE_DEVPTS -g -O0 -DGITID=\"dc26065\" -Wno-format-y2k -DSYSCONF_PREFIX=\"\" -c -o connection.o connection.cc
g++ -pipe -fdollars-in-identifiers -fsigned-char -Wall -Wno-unused -Wno-uninitialized -I../libdap -I../include -DVERSION=\"3.27\" -D_XOPEN_SOURCE -D_DEFAULT_SOURCE -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSHADOW_PWD -DDNETUSE_DEVPTS -g -O0 -DGITID=\"dc26065\" -Wno-format-y2k -DSYSCONF_PREFIX=\"\" -c -o protocol.o protocol.cc
during RTL pass: expand
In file included from connection.cc:49:
protocol.h: In constructor rCydap_bytes::dap_bytes(int)rCO:
protocol.h:28:44: internal compiler error: Illegal instruction
28 | value = (unsigned char *)malloc(size+1); // May be a string
| ~~~~~~^~~~~~~~
0x2436876 diagnostics::context::diagnostic_impl(rich_location*, diagnostics::metadata const*, diagnostics::option_id, char const*, __va_list_tag (*) [1], diagnostics::kind)
???:0
0x242f83f internal_error(char const*, ...)
???:0
0xb78dbd expand_call(tree_node*, rtx_def*, int)
???:0
0xca5f01 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
???:0
0xcb387c store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
0xcb6135 expand_assignment(tree_node*, tree_node*, bool)
???:0
/usr/libexec/gcc/x86_64-slackware-linux/16.2.0/cc1plus -quiet -I ../libdap -I ../include -D_GNU_SOURCE -D VERSION="3.27" -D _XOPEN_SOURCE -D _DEFAULT_SOURCE -D _GNU_SOURCE -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D SHADOW_PWD -D DNETUSE_DEVPTS -D GITID="dc26065" -D SYSCONF_PREFIX="" connection.cc -quiet -dumpbase connection.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -g -O0 -Wall -Wno-unused -Wno-uninitialized -Wno-format-y2k -fdollars-in-identifiers -fsigned-char -o -
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[1]: *** [Makefile:26: connection.o] Error 1
make[1]: *** Waiting for unfinished jobs....
during RTL pass: expand
In file included from protocol.cc:46:
protocol.h: In constructor rCydap_bytes::dap_bytes(int)rCO:
protocol.h:28:44: internal compiler error: Illegal instruction
28 | value = (unsigned char *)malloc(size+1); // May be a string
| ~~~~~~^~~~~~~~
0x2436876 diagnostics::context::diagnostic_impl(rich_location*, diagnostics::metadata const*, diagnostics::option_id, char const*, __va_list_tag (*) [1], diagnostics::kind)
???:0
0x242f83f internal_error(char const*, ...)
???:0
0xb78dbd expand_call(tree_node*, rtx_def*, int)
???:0
0xca5f01 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
???:0
0xcb387c store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
0xcb6135 expand_assignment(tree_node*, tree_node*, bool)
???:0
/usr/libexec/gcc/x86_64-slackware-linux/16.2.0/cc1plus -quiet -I ../libdap -I ../include -D_GNU_SOURCE -D VERSION="3.27" -D _XOPEN_SOURCE -D _DEFAULT_SOURCE -D _GNU_SOURCE -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D SHADOW_PWD -D DNETUSE_DEVPTS -D GITID="dc26065" -D SYSCONF_PREFIX="" protocol.cc -quiet -dumpbase protocol.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -g -O0 -Wall -Wno-unused -Wno-uninitialized -Wno-format-y2k -fdollars-in-identifiers -fsigned-char -o -
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[1]: *** [Makefile:26: protocol.o] Error 1
make[1]: Leaving directory '/usr/src/decnet3/LinuxDECnet/dnprogs/libdap'
make: *** [Makefile:27: all] Error 2
make exited with status code 2

Tue Sep 29 18:34:04 2026
----------------
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/16.2.0/specs COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/16.2.0/lto-wrapper Target: x86_64-slackware-linux
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol --enable-threads=posix --enable-checking=release --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit --disable-libssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-plugin --enable-lto --disable-install-libiberty --disable-werror --with-gnu-ld --with-isl --verbose --with-arch-directory=amd64 --disable-gtktest --enable-clocale=gnu --with-arch=x86-64 --enable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.2.0 (GCC)


I don't think building with clang/++ is possible due to a kernel module
being involved.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Tue, 29 Sep 2026 19:07:36 -0400, jayjwa wrote:

protocol.h:28:44: internal compiler error: Illegal instruction

Maybe the error text is somehow misleading, but "Illegal instruction"
output from a program usually means that the program has been compiled to utilize more or less unusual instructions (like some specific version of
MMX, SSE or AVX) and now is being run on a CPU which lacks support for
those instructions.

Assuming that you are running stable 64 bit Slackware 15.0 and studying
how gcc was built at http://ftp.slackware.com/pub/slackware/ slackware64-15.0/source/d/gcc/gcc.SlackBuild there doesn't seem to be any
such flags for x86_64. However, if you are running 32 bit Slackware 15.0, those gcc i586 packages has been compiled to require the instruction set
of an i586 yet tuned for i686 CPUs.

So, are you running 32 bit Slackware? If so, maybe the Ryzen 9 has
omitted some old 32 bit instructions?

But in most cases, newer CPUs support the instructions of all older CPUs
and sometimes add some more instructions. Could it be that your CPU is
broken, lacking support for some instruction that it were supposed to
have?

Maybe it will work better if you recompile gcc with -march=native ?

regards Henrik
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

Assuming that you are running stable 64 bit Slackware 15.0 and studying
how gcc was built at http://ftp.slackware.com/pub/slackware/ slackware64-15.0/source/d/gcc/gcc.SlackBuild there doesn't seem to be any such flags for x86_64. However, if you are running 32 bit Slackware 15.0, those gcc i586 packages has been compiled to require the instruction set
of an i586 yet tuned for i686 CPUs.

It's Slackware Current from end of Sept. on a new 64-bit Ryzen 9. The
Ryzen 5 has no such issues. Most, but not all, software has built fine
the 9. All builds fine on the 5.

But in most cases, newer CPUs support the instructions of all older CPUs
and sometimes add some more instructions. Could it be that your CPU is broken, lacking support for some instruction that it were supposed to
have?

It better not be! It's brand new and I payed a good buck for it.

Maybe it will work better if you recompile gcc with -march=native ?

I want to avoid a rebuild of GCC if I can, because then *my* GCC won't
sync with the OS's one and Bad Things can happen. I'll play around with compiler flags in the meantime. I'm on the GCC mailing list so last
resort is check there, but I though I'd try everything else first before
making a dumb mistake in front of the GCC masters.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Wed, 30 Sep 2026 10:45:36 -0400, jayjwa wrote:

[snip]

I want to avoid a rebuild of GCC if I can, because then *my* GCC won't
sync with the OS's one and Bad Things can happen. I'll play around with compiler flags in the meantime. I'm on the GCC mailing list so last
resort is check there, but I though I'd try everything else first before making a dumb mistake in front of the GCC masters.

I'm pleased to encounter someone who attempts to proactively diagnose
problems before calling in the experts, but, I must point out that
the experts /want/ you to contact them. Your original post included
these messages from GCC
In file included from connection.cc:49:
protocol.h: In constructor rCydap_bytes::dap_bytes(int)rCO:
protocol.h:28:44: internal compiler error: Illegal instruction
...
/usr/libexec/gcc/x86_64-slackware-linux/16.2.0/cc1plus -quiet -I ../libdap -I ../include -D_GNU_SOURCE -D VERSION="3.27" -D _XOPEN_SOURCE -D _DEFAULT_SOURCE -D _GNU_SOURCE -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D SHADOW_PWD -D DNETUSE_DEVPTS -D GITID="dc26065" -D SYSCONF_PREFIX="" connection.cc -quiet -dumpbase connection.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -g -O0 -Wall -Wno-unused -Wno-uninitialized -Wno-format-y2k -fdollars-in-identifiers -fsigned-char -o -
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

It looks like the GCC masters would like to hear from you.

Luck be with you.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Last ditch effort - I reinstalled G++ on the machine in question and it
works. All I can think of is that the USB stick I used for the image is
getting "holes" in it. One of the packages I knew to be good was not
installing and I had to fetch a new copy of it (same stick) and it
worked. Now GCC is working again. All I can figure is some part of its inner-workings got corrupted in there. And, being a new/recent CPU...you
can see my train of thought.

This is *exactly* why I hate to go to the devs - I have a long history
of doing this. So bad, in fact, that I usually wait a day or two before
bring it up with anyone.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Wed, 30 Sep 2026 21:25:51 -0400, jayjwa wrote:

All I can think of is that the USB stick I used for the image is
getting "holes" in it. One of the packages I knew to be good was not installing and I had to fetch a new copy of it (same stick) and it
worked.

If you can't trust your ways to transfer Slackware packages, all stock Slackware packages come with a .asc file which can be used together with
gpg to check that the packages is OK and from the right source. Even
easier is to use the CHECKSUMS.md5 file to check all the packages at once.

Speaking of being able to trust hardware... Last weeks I have had some machines compressing data with xz, on one of those machines xz sometimes segfaults. Sometimes that machine also hangs hard, requiring a reboot. At reboot, the machine tells me that its ECC RAM has been able to find correctable memory errors in one of two DIMMS. Most likely, the machine
has also suffered from some non correctable errors causing those
segfaults and hangs.

Bying machines and memory supporting ECC is more expensive than memory
without ECC, but it is really nice to have those days when the memory
starts to go bad. In this case, I can say that this 15 year old machine
has a bad memory. There is nothing wrong with the software installation,
no point in trying to do a reinstall of the OS. The choices are to
identiyfy the bad DIMM and replace it or simply remove it and let the
machine continue its life with less RAM, or to simply retire that 15 year
old hardware.

Without ECC, I might have spent days or weeks trying to reinstall
software, and maybe taking the machine offline for some day to run
memtest. Now, with ECC, the machine itself has pinpointed the problem.

regards Henrik
--- Synchronet 3.22a-Linux NewsLink 1.2