Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 712554

Summary: sys-devel/gcc-9 fails to build on a PowerPC G3 (750FX) with an illegal instruction error
Product: Gentoo Linux Reporter: Daniel Gurney <daniel>
Component: Current packagesAssignee: PPC Porters <ppc>
Status: RESOLVED WORKSFORME    
Severity: normal CC: jstein, toolchain
Priority: Normal    
Version: unspecified   
Hardware: PPC   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Requested GCC log file

Description Daniel Gurney 2020-03-14 18:41:46 UTC
Created attachment 619134 [details]
Requested GCC log file

While attempting to install Gentoo on my iBook G3, gcc-9.3.0 fails to build. It doesn't seem to matter what optimization settings I try using. I can also replicate the same failure with 9.2.0-r4.
Comment 1 Daniel Gurney 2020-03-14 18:48:57 UTC
Portage 2.3.89 (python 3.6.10-final-0, default/linux/powerpc/ppc32/17.0, gcc-9.2.0, glibc-2.29-r7, 5.4.5-mc0-easy ppc)
=================================================================
System uname: Linux-5.4.5-mc0-easy-ppc-750FX-with-gentoo-2.6
KiB Mem:      372852 total,     89356 free
KiB Swap:     655356 total,    648700 free
Timestamp of repository gentoo: Sat, 14 Mar 2020 12:39:55 +0000
Head commit of repository gentoo: ef2e89336dcbf6947712a574bc9004d9fdb3088f

sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.33.1 p2) 2.33.1
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.30.1::gentoo
dev-lang/python:          2.7.17-r1::gentoo, 3.6.10::gentoo, 3.7.6::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.42.1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.69-r4::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.33.1-r1::gentoo
sys-devel/gcc:            9.2.0-r2::gentoo
sys-devel/gcc-config:     2.2.1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.29-r7::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/gentoo
    priority: -1000

ACCEPT_KEYWORDS="ppc ~ppc"
ACCEPT_LICENSE="@FREE"
CBUILD="powerpc-unknown-linux-gnu"
CFLAGS="-O2 -mcpu=powerpc -pipe"
CHOST="powerpc-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -mcpu=powerpc -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--keep-going --autounmask=y"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -mcpu=powerpc -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -mcpu=powerpc -pipe"
GENTOO_MIRRORS="https://mirror.yandex.ru/gentoo-distfiles/"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="acl berkdb big-endian bzip2 cli crypt cxx dri fortran gdbm iconv ipv6 ncurses nls nptl offensive openmp pam pcre ppc readline seccomp split-usr ssl systemd tcpd unicode xattr zlib" ABI_PPC="32" ADA_TARGET="gnat_2018" ALSA_CARDS="aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas aoa-toonie powermac usb-audio via82xx" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="fbdev glint mga nv r128 radeon dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev 2020-03-14 22:16:47 UTC
Can you get a backtrace and disassembly around this instruction? I wonder if it's a jump to unexpected location or emission of too new instruction for you ISA.

The procedure should look like following:
1. run failing gcc command from build.log to make sure it still happens
2. find a core dump core.<number>. 'file core.<number>' should tell you which executable crashed.
3. run 'gdb part/to/executable core.<number>'
4. run 'bt' and 'disassemble' commands in gdb session and post output.
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2020-03-29 20:03:49 UTC
Also note: the crashing compiler is your existing installed 9.2.0 compiler, not newly built one:

"""
powerpc-unknown-linux-gnu-g++ -std=gnu++98 -fno-PIE -c -fno-PIE     -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc/. -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc/../include -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc/../libcpp/include  -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/gcc/../libbacktrace   -o gimple-match.o -MT gimple-match.o -MMD -MP -MF ./.deps/gimple-match.TPo gimple-match.c
during GIMPLE pass: ssa
gimple-match.c: In function 'bool gimple_simplify_BIT_XOR_EXPR(gimple_match_op*, gimple**, tree_node* (*)(tree), code_helper, tree, tree, tree)':
gimple-match.c:100129:1: internal compiler error: Illegal instruction
100129 | }
       | ^
Please submit a full bug report,
"""
Comment 4 Sergei Trofimovich (RETIRED) gentoo-dev 2020-04-11 08:57:30 UTC
Spent some time getting the same build to match gimple-match.c:100129 line numbers. My gimple-match.c is a few thousand lines shorter than that.

Closing as NEEDINFO.
Comment 5 Daniel Gurney 2020-04-11 18:49:34 UTC
Sorry for the delay, I had to set this aside for a bit. I tried to follow your instructions for a backtrace+disassembly, but it seems that whenever I manually run the failed command, it goes through without any error or warning output. I also noticed that the failing command is not always the same, which probably explains this behavior to some extent. I tried getting a core dump via other means, but nothing seems to get generated at the location I set. ulimit -c was set to unlimited.

At this point the only thing I can think of trying is cross-compiling gcc-9.3.0 on another system, packaging it up, and then installing it and seeing if rebuilding itself works. I'll report back if that makes a (preferably positive) difference...
Comment 6 Daniel Gurney 2020-04-11 21:48:20 UTC
It made no meaningful difference, still fails eventually. I even replaced glibc and binutils with cross-compiled packages, in vain hope that it would have helped, but as (probably) expected it made no difference. What can I try next?
Comment 7 Sergei Trofimovich (RETIRED) gentoo-dev 2020-04-11 23:09:32 UTC
Does 'dmesg' report an instruction CPU tried to execute? I hope to see a byte (or word) sequence.
Comment 8 Daniel Gurney 2020-04-12 11:43:58 UTC
dmesg has nothing related to instructions, I used ignore_loglevel so that shouldn't have been an issue. What else could I do to get useful information out of this?
Comment 9 Sergei Trofimovich (RETIRED) gentoo-dev 2020-04-12 15:21:29 UTC
Do I understand correctly that you get different errors every time you attempt to emerge gcc?

That might hint at either kernel memory corruption bug or at hardware problems (cpu overheat, memory faults).

Would be nice to run a ppc equivalent of sys-apps/memtest86+ to check if hardware is working on mild workloads.
Comment 10 Daniel Gurney 2020-04-12 19:25:20 UTC
The illegal instruction error is the same, but the source file that triggers the error differs per each run. And yes, at this point since I've tried so many software tricks I think a hardware problem is indeed the most likely explanation. The memory in the machine seems to be fine when tested with Apple Hardware Test and sys-apps/memtester, so the issue is elsewhere. In any case I think it's fine to close this bug for now since the issue doesn't seem to be software-related, I'll let you or someone else figure out the best status for it.
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2020-04-12 19:53:08 UTC
Let's close it as WORKSFORME.