Not sure how much info is really needed here, but it looks like there's an ICE in the "stage 1" compiler (i.e. "xgcc"): libtool: compile: /storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/./gcc/xgcc -shared-libgcc -B/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/./gcc -nostdinc++ -L/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/powerpc64-unknown-linux-gnu/bin/ -B/usr/powerpc64-unknown-linux-gnu/lib/ -isystem /usr/powerpc64-unknown-linux-gnu/include -isystem /usr/powerpc64-unknown-linux-gnu/sys-include -I/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/../libgcc -I/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -fvtable-verify=std -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hash_tr1.lo -g -O2 -D_GNU_SOURCE -c /storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/src/c++98/hash_tr1.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o hash_tr1.o In file included from /storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/gcc-7.3.0/libstdc++-v3/src/c++98/complex_io.cc:25:0: /storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/include/complex: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&) [with _Tp = long double; _CharT = wchar_t; _Traits = std::char_traits<wchar_t>]': /storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/include/complex:528:5: internal compiler error: Segmentation fault operator<<(basic_ostream<_CharT, _Traits>& __os, const complex<_Tp>& __x) ^~~~~~~~ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.gentoo.org/> for instructions. make[5]: *** [Makefile:565: complex_io.lo] Error 1 Let me know what other relevant information is needed. Note that cross-aarch64/gcc-7.3.0-r3 compiled just fine on the same system.
Realized I neglected to put in the host details: amd64 system, C(XX)FLAGS=-O2 -pipe -march=corei7, it's a Core i7-920 CPU.
Thank you for the report. Please recompile and *attach* the logfiles and paste the emerge info as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket Please reopen this ticket (Status:unconfirmed) afterwards.
(In reply to Jonas Stein from comment #2) > Thank you for the report. Please recompile and *attach* the logfiles and > paste the emerge info as described on > https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket > Please reopen this ticket (Status:unconfirmed) afterwards. I understand your intentions, but this is misguided. Anyone working on this bug will have to attempt to reproduce it at which point they have logs. There is sufficient information here to begin investigation.
Can you attach build logs that crossdev usually dumps when you build cross toolchain? It usually contains all low-level info used configuration (I failed to reproduce ICE locally).
I configured the crossdev setup ages ago (successfully), and have just been upgrading whatever emerge -u world tells me. Let's say you did reproduce the ICE, what would you do next? I'm happy to do the work, I just have no idea how to proceed. I don't have a ton of experience debugging ebuild-initiated builds, but am otherwise generally competent. The cross setup is targeted at a PPC64 G5 PowerMac7,2 or so (going from memory, one of the AGP G5's) -- not sure if that matters -- the gcc can handle the whole range of chips as I recall, and I can't imagine it would affect the stage1 compiler either way.
(In reply to Ilia Mirkin from comment #5) > I configured the crossdev setup ages ago (successfully), and have just been > upgrading whatever emerge -u world tells me. Aha, then posting build.log of gcc failure should be good enough. > Let's say you did reproduce the ICE, what would you do next? I'm happy to do the work, I just have no idea how to proceed. I don't have a ton of experience debugging ebuild-initiated builds, but am otherwise generally competent. Something along these lines: https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide
(In reply to Ilia Mirkin from comment #0) > /storage/tmp/portage/portage/cross-powerpc64-unknown-linux-gnu/gcc-7.3.0-r3/ > work/build/powerpc64-unknown-linux-gnu/libstdc++-v3/include/complex:528:5: > internal compiler error: Segmentation fault > operator<<(basic_ostream<_CharT, _Traits>& __os, const complex<_Tp>& > __x) > ^~~~~~~~ Also, another avenue to explore. This also vaguely ring a bell of: https://wiki.gentoo.org/wiki/Mpfr4-update-guide Make sure mpc is linked against latest SONAME version of mpfr: $ scanelf -n /usr/lib64/libmpfr.so /usr/lib64/libmpc.so TYPE NEEDED FILE ET_DYN libgmp.so.10,libc.so.6,ld-linux-x86-64.so.2 /usr/lib64/libmpfr.so ET_DYN libmpfr.so.4,libgmp.so.10,libc.so.6 /usr/lib64/libmpc.so $ qlist mpfr | fgrep libmpfr /usr/lib32/libmpfr.so.4 /usr/lib32/libmpfr.so /usr/lib32/libmpfr.so.4.1.6 /usr/lib64/libmpfr.so.4 /usr/lib64/libmpfr.so /usr/lib64/libmpfr.so.4.1.6 Here libmpc.so and host gcc are linked against latest libmpfr.so.4 (mpfr-3). Problems usually happen when you have libmpc.so linked agains older version of mpfr but newly built stage1 is inpled againt new mpfr and mpc. That pulls in two versions of libmpc. Let's check it's not the case.
Created attachment 544742 [details] build log I believe my mprf situation is in order -- mpc has .4 in it. And all this worked for aarch64 and armv7a. powerpc64 seems somehow special.
Created attachment 544744 [details] compatibility.ii And I have the -save-temps output file that dies with an error. Will play with creduce next.
(In reply to Ilia Mirkin from comment #9) > Created attachment 544744 [details] > compatibility.ii > > And I have the -save-temps output file that dies with an error. Will play > with creduce next. Ah, you have USE=vtv enabled for powerpc target. crossdev was tough to disable vtv by default on most arches: https://bugs.gentoo.org/618786 You might want to disable it as well.
Created attachment 544746 [details] reduced test case creduce is pretty awesome. So the attached fails with testing.ii: In function 'void e()': testing.ii:6:6: internal compiler error: Segmentation fault void e() try { d->b(); } catch (int) { I will try with USE=-vtv next. Seems like it could be very much related. (FWIW I didn't explicitly enable it myself, but it probably flows down from some profile or other default setting.)
And before doing -vtv, here's what bt looks like on xgcc with the reduced test case. Doing "bt full" provided no additional info. Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault. [Switching to process 11875] 0x0000000000d2768c in call_ABI_of_interest(tree_node*) () (gdb) bt #0 0x0000000000d2768c in call_ABI_of_interest(tree_node*) () #1 0x0000000000d3ad8a in init_cumulative_args(rs6000_args*, tree_node*, rtx_def*, int, int, int, tree_node*, machine_mode) () #2 0x000000000072c9ee in expand_call(tree_node*, rtx_def*, int) () #3 0x000000000082367e in expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) () #4 0x000000000082d9d3 in store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) () #5 0x000000000082e687 in expand_assignment(tree_node*, tree_node*, bool) () #6 0x000000000073c8d2 in expand_gimple_stmt(gimple*) () #7 0x000000000073dac0 in expand_gimple_basic_block(basic_block_def*, bool) () #8 0x0000000000742def in (anonymous namespace)::pass_expand::execute(function*) () #9 0x00000000009fb747 in execute_one_pass(opt_pass*) () #10 0x00000000009fbf51 in execute_pass_list_1(opt_pass*) () #11 0x00000000009fbfa5 in execute_pass_list(function*, opt_pass*) () #12 0x000000000076d4f2 in cgraph_node::expand() () #13 0x000000000076e899 in symbol_table::compile() [clone .part.50] () #14 0x0000000000770587 in symbol_table::finalize_compilation_unit() () #15 0x0000000000ab2e7e in compile_file() () #16 0x000000000054e183 in toplev::main(int, char**) () #17 0x000000000055047b in main ()
Confirmed that all is well with USE=-vtv. I should have included the USE flags up front, I thought I had... sorry about that!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f437c7c0233294f197514f3b6ab8a4a24736719b commit f437c7c0233294f197514f3b6ab8a4a24736719b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-02-15 07:49:26 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-02-15 07:53:19 +0000 toolchain.eclass: never pass --enable-libvtv to ./configure gcc treats --enable-libvtv as an override on top of autodetection. It it never what we want. Happens to break at least powerpc64 cross-compilers: https://bugs.gentoo.org/661252 Reported-by: Ilia Mirkin Closes: https://bugs.gentoo.org/661252 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
