libgcc10 @ 10.3.0_0+universal.darwin_15.i386-x86_64: libgcc/libgcc2.c:1989:10: internal compiler error: Illegal instruction: 4 building mulxc3

[thetrial (alabay)]

I’m not quite sure what could be the sticking point. I guess the interesting thing starts at line 163312. Shortly after that the mentioned error occurs.

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/gcc-10.3.0/libgcc/libgcc2.c: In function '__mulxc3':
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/gcc-10.3.0/libgcc/libgcc2.c:1989:10: internal compiler error: Illegal instruction: 4
:info:build  1989 |       if (isinf (a) || isinf (b))
:info:build       |          ^
:info:build libbacktrace could not find executable to open
:info:build Please submit a full bug report,
:info:build with preprocessed source if appropriate.
:info:build See <https://trac.macports.org/newticket> for instructions.
:info:build make[5]: *** [_mulxc3.o] Error 1
:info:build make[5]: *** Waiting for unfinished jobs....
:info:build make[5]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build/x86_64-apple-darwin15/i386/libgcc'
:info:build make[4]: *** [multi-do] Error 1
:info:build make[4]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build/x86_64-apple-darwin15/libgcc'
:info:build make[3]: *** [all-multi] Error 2
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build/x86_64-apple-darwin15/libgcc'
:info:build make[2]: *** [all-stage1-target-libgcc] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build'
:info:build make[1]: *** [stage1-bubble] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build'
:info:build make: *** [bootstrap-lean] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc10/libgcc10/work/build" && /usr/bin/make -j4 -w bootstrap-lean 
:info:build Exit code: 2
:error:build Failed to build libgcc10: command execution failed
:debug:build Error code: CHILDSTATUS 47736 2

I’ll also attach the 7zipped main.log

[thetrial (alabay)]

7zipped main log.

[kencu (Ken)]

I have been seeing this error on other systems as well (eg 10.7), but not consistently I noticed.

I believe it may be related to our cctools modifications to send the assembly to clang, but I am not certain about that.

It may also be related to building i386 / universal.

I have at times got past it just by rebuilding.

[jmroot (Joshua Root)]

This is the same error as in #62662.

[kencu (Ken)]

Exactly. I have a set of ENV_VARS and a patch for gcc to accept them during the build that turns off our assembler mods for cctools.

We may need to use those when building gcc, as Iain does not test his builds against our modified assembler setup on MacPorts, only against the system assembler and default toolchain settings.

Perhaps he might have some insight into what is going on here, though.

[thetrial (alabay)]

When I read cctools … is it just coincidental that I recently had a problem with cctools? Or maybe an esoteric link? #62693

[kencu (Ken)]

coincidence.

By default the system will use a certain assembler. This was causing lots of build failures for newer software using newer assembly, so that was changed a few years ago to use the most current clang available.

This has been 99% a good thing, but rarely certain software does not expect it, esp building gcc. But it's so complicated to figure out exactly what is wrong that only a few people have the insight into the issue sufficiently to know.

Last one we fixed, gcc was configuring itself with a certain expectation of the assembler capabilities based on the new assembly being tested for an found, but the rest of the toolchain could not support the newer features.

[thetrial (alabay)]

I have to add three things, respecting this and maybe even #62693:

• Due to the problems I had only on one machine, and them not appearing on the other – I decided to »transplant« /opt from one to the other. Applying root/wheel 755 was a bit tricky, but I did it with batchmod. Afterwards I made a port clean --all all. At the moment everything runs fine except keepassxc, that seems abandoned, #62220.
• While doing that I noticed that there is a specialty that might (?) play a role: I use ccache. I applied a ccache -C and deleted all subfolders in its directory.
• Last but not least, I think this is the right place and time to mention a very big thank you for you all, who you are so engaged in macports! :-)