|Summary:||lang/gcc10-devel, 20190901 snapshot: internal compiler error: Segmentation fault|
|Product:||Ports & Packages||Reporter:||Dimitry Andric <dim>|
|Component:||Individual Port(s)||Assignee:||Gerald Pfeifer <gerald>|
|Severity:||Affects Some People||CC:||dim, lantw44|
Description Dimitry Andric 2019-09-07 11:17:21 UTC
During the first stage, I see: during RTL pass: stv /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath/math/remainderq.c: In function 'remainderq': /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath/math/remainderq.c:69:1: internal compiler error: Segmentation fault 69 | } | ^ no stack trace because unwind library not available I tried rebuilding the port with WITH_DEBUG=1, but for some reason it still doesn't show much info in the backtrace: (gdb) run Starting program: /usr/work/usr/ports/lang/gcc10-devel/work/.build/gcc/cc1 -quiet -v -I . -I /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath -I /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath/../include -imultilib 32 -iprefix /usr/work/usr/ports/lang/gcc10-devel/work/.build/gcc/../lib/gcc10/gcc/x86_64-portbld-freebsd12.1/10.0.0/ -isystem /usr/work/usr/ports/lang/gcc10-devel/work/.build/./gcc/include -isystem /usr/work/usr/ports/lang/gcc10-devel/work/.build/./gcc/include-fixed -MD math/.libs/remainderq.d -MF math/.deps/remainderq.Tpo -MP -MT math/remainderq.lo -D HAVE_CONFIG_H -D LIBICONV_PLUG -D PIC -isystem /usr/local/x86_64-portbld-freebsd12.1/include -isystem /usr/local/x86_64-portbld-freebsd12.1/sys-include /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath/math/remainderq.c -quiet -dumpbase remainderq.c -march=haswell -m32 -auxbase-strip math/.libs/remainderq.o -g -O2 -version -fno-strict-aliasing -fPIC -o /tmp/cckRfWIp.s warning: File "/usr/local/lib/libisl.so.19.0.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". GNU C17 (FreeBSD Ports Collection) version 10.0.0 20190901 (experimental) (x86_64-portbld-freebsd12.1) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/x86_64-portbld-freebsd12.1/include" ignoring nonexistent directory "/usr/local/x86_64-portbld-freebsd12.1/sys-include" ignoring nonexistent directory "/usr/work/usr/ports/lang/gcc10-devel/work/.build/gcc/../lib/gcc10/gcc/x86_64-portbld-freebsd12.1/10.0.0/include" ignoring nonexistent directory "/usr/work/usr/ports/lang/gcc10-devel/work/.build/gcc/../lib/gcc10/gcc/x86_64-portbld-freebsd12.1/10.0.0/include-fixed" ignoring nonexistent directory "/usr/work/usr/ports/lang/gcc10-devel/work/.build/gcc/../lib/gcc10/gcc/x86_64-portbld-freebsd12.1/10.0.0/../../../../../x86_64-portbld-freebsd12.1/include" ignoring nonexistent directory "/usr/local/lib/gcc10/gcc/x86_64-portbld-freebsd12.1/10.0.0/include" ignoring nonexistent directory "/usr/local/lib/gcc10/gcc/x86_64-portbld-freebsd12.1/10.0.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc10/gcc/../../../x86_64-portbld-freebsd12.1/include" #include "..." search starts here: #include <...> search starts here: . /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath /usr/work/usr/ports/lang/gcc10-devel/work/gcc-10-20190901/libquadmath/../include /usr/work/usr/ports/lang/gcc10-devel/work/.build/./gcc/include /usr/work/usr/ports/lang/gcc10-devel/work/.build/./gcc/include-fixed /usr/local/include /usr/include End of search list. GNU C17 (FreeBSD Ports Collection) version 10.0.0 20190901 (experimental) (x86_64-portbld-freebsd12.1) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: ebdfffeb7612750c02e465841f91b5d8 Program received signal SIGSEGV, Segmentation fault. 0x00000000013ce4f3 in gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) () (gdb) bt #0 0x00000000013ce4f3 in gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) () #1 0x0000000001f9592f in (anonymous namespace)::general_scalar_chain::convert_registers() () #2 0x0000000001f933f6 in (anonymous namespace)::pass_stv::execute(function*) () #3 0x0000000001970b3d in execute_one_pass(opt_pass*) () #4 0x0000000001971508 in execute_pass_list_1(opt_pass*) () #5 0x000000000197151a in execute_pass_list_1(opt_pass*) () #6 0x00000000019633aa in execute_pass_list(function*, opt_pass*) () #7 0x00000000012d19d2 in cgraph_node::expand() () #8 0x00000000012d50c4 in symbol_table::compile() () #9 0x00000000012d5690 in symbol_table::finalize_compilation_unit() () #10 0x0000000001b43c64 in compile_file() () #11 0x0000000001b436ef in toplev::main(int, char**) () #12 0x0000000001f97bef in main ()
Comment 1 Dimitry Andric 2019-09-07 11:18:34 UTC
Note that the 20190825 snapshot built just fine. So this seems to be a regression introduced in that latest snapshot.
Comment 2 Gerald Pfeifer 2019-09-07 23:57:22 UTC
Ui, that looks like a tricky one, since it's the compiler (GCC) just built with clang, so could be, among others, miscompilation (-> clang) or undefined behavior (-> GCC). I'll see that I update to this Sunday's snapshot on Monday or Tuesday, and if you could then see if it still reproduces? Also would be interesting to see what may be specific about your settings, since I have not seen any other report. Did you configure -march=haswell somewhere? Does it make a difference if you remove that? Anything else? What happens if you build GCC with GCC, e.g. by adding USE_GCC=yes to the Makefile (which will use GCC 9 by default)?
Comment 3 commit-hook 2019-09-10 11:10:06 UTC
A commit references this bug: Author: gerald Date: Tue Sep 10 11:09:23 UTC 2019 New revision: 511753 URL: https://svnweb.freebsd.org/changeset/ports/511753 Log: Update to the 20190908 snapshot of GCC 10.0.0. This may (or may not) address a build regression (with clang) that dim@ reported.  PR: 240387  Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo
Comment 4 Dimitry Andric 2019-09-11 09:49:15 UTC
FWIW, the 20190908 snapshot segfaults in the same manner, when compiled with clang. Building it with USE_GCC=yes seems to work, at least it is still going after half an hour or so. I would really like to build the first stages with -fsanitize=address, but it seems to be failing on linking one of its internal binaries, in that case. I will probably have to bisect using the upstream git repository...
Comment 5 Gerald Pfeifer 2019-09-11 11:17:29 UTC
(In reply to Dimitry Andric from comment #4) > Building it with USE_GCC=yes seems to work, at least it is still going > after half an hour or so. Should we consider putting this in place for the time being? > I will probably have to bisect using the upstream git repository... That would be great, thank you!
Comment 6 Dimitry Andric 2019-09-13 15:25:18 UTC
(In reply to Gerald Pfeifer from comment #5) > Should we consider putting this in place for the time being? Sure, that is fine for a temporary workaround. >> I will probably have to bisect using the upstream git repository... Since I had lots of problems getting trunk to compile on FreeBSD (it would error out when linking with lld, saying it could not find -lc), I luckily found out that it also segfaulted on Linux, when compiling with clang. Bisection showed that this regressed with https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274953: 1521be593e208321b668b47a395b448a206f1f21 is the first bad commit commit 1521be593e208321b668b47a395b448a206f1f21 Author: rguenth <rguenth@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Tue Aug 27 12:46:07 2019 +0000 2019-08-27 Richard Biener <firstname.lastname@example.org> * config/i386/i386-features.h (general_scalar_chain::~general_scalar_chain): Add. (general_scalar_chain::insns_conv): New bitmap. (general_scalar_chain::n_sse_to_integer): New. (general_scalar_chain::n_integer_to_sse): Likewise. (general_scalar_chain::make_vector_copies): Adjust signature. * config/i386/i386-features.c (general_scalar_chain::general_scalar_chain): Outline, initialize new members. (general_scalar_chain::~general_scalar_chain): New. (general_scalar_chain::mark_dual_mode_def): Record insns we need to insert conversions at and count them. (general_scalar_chain::compute_convert_gain): Account for conversion instructions at chain boundary. (general_scalar_chain::make_vector_copies): Generate a single copy for a def by a specific insn. (general_scalar_chain::convert_registers): First populate defs_map, then make copies at out-of chain insns. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@274953 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 69c2d0a60561dc4ae58066a6de75f81b53acc642 a17f631ae2f2c6549837e7f7f27408a631b134e2 M gcc Running the xgcc command line under valgrind resulted in: ==19771== Invalid read of size 1 ==19771== at 0x82D7DC: gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) (src/gcc/gcc/emit-rtl.c:1013) ==19771== by 0xFFE42E: make_vector_copies (src/gcc/gcc/config/i386/i386-features.c:716) ==19771== by 0xFFE42E: (anonymous namespace)::general_scalar_chain::convert_registers() (src/gcc/gcc/config/i386/i386-features.c:1173) ==19771== by 0xFFC3B8: convert (src/gcc/gcc/config/i386/i386-features.c:1192) ==19771== by 0xFFC3B8: convert_scalars_to_vector (src/gcc/gcc/config/i386/i386-features.c:1629) ==19771== by 0xFFC3B8: (anonymous namespace)::pass_stv::execute(function*) (src/gcc/gcc/config/i386/i386-features.c:1767) ==19771== by 0xB3463D: execute_one_pass(opt_pass*) (src/gcc/gcc/passes.c:2494) ==19771== by 0xB35047: execute_pass_list_1(opt_pass*) (src/gcc/gcc/passes.c:2580) ==19771== by 0xB35059: execute_pass_list_1(opt_pass*) (src/gcc/gcc/passes.c:2581) ==19771== by 0xB27164: execute_pass_list(function*, opt_pass*) (src/gcc/gcc/passes.c:2591) ==19771== by 0x768E5A: cgraph_node::expand() (src/gcc/gcc/cgraphunit.c:2194) ==19771== by 0x76C4DD: expand_all_functions (src/gcc/gcc/cgraphunit.c:2332) ==19771== by 0x76C4DD: symbol_table::compile() (src/gcc/gcc/cgraphunit.c:2688) ==19771== by 0x76CA4F: symbol_table::finalize_compilation_unit() (src/gcc/gcc/cgraphunit.c:2868) ==19771== by 0xC150F3: compile_file() (src/gcc/gcc/toplev.c:481) ==19771== by 0xC14BCE: do_compile (src/gcc/gcc/toplev.c:2166) ==19771== by 0xC14BCE: toplev::main(int, char**) (src/gcc/gcc/toplev.c:2301) ==19771== Address 0x2 is not stack'd, malloc'd or (recently) free'd ==19771== during RTL pass: stv /home/dim/src/gcc/libgcc/config/libbid/bid128_fma.c: In function 'bid128_ext_fma': /home/dim/src/gcc/libgcc/config/libbid/bid128_fma.c:3569:1: internal compiler error: Segmentation fault 3569 | } | ^ Unfortunately this did not add much more information than debugging with gdb. It looks like the rtx_def* parameter passed to get_rtx_SUBREG() is simply NULL, while this Should Not Happen. Somewhere before that call, the rtx_def pointer is retrieved from some sort of hash map, and it seems that in this case the retrieval fails and results in a NULL pointer. Maybe this should be reported upstream?
Comment 7 Dimitry Andric 2019-09-13 20:18:27 UTC
Comment 8 Dimitry Andric 2019-09-20 09:02:04 UTC
Comment 9 Dimitry Andric 2019-09-20 21:14:03 UTC
I assume this will end up in the next snapshot; are these taken weekly? If so, let's close this bug after that next snapshot is imported.
Comment 10 Gerald Pfeifer 2019-09-21 22:37:43 UTC
(In reply to Dimitry Andric from comment #9) > I assume this will end up in the next snapshot; are these taken weekly? Yes, these usually happen weekly on the GCC side and I try to update ports for each one. For this one I'm working to pull the fix into the current port today; fixed is fixed. ;-) Thank you for the great detective work, Dimitry, and engaging with upstream around it!
Comment 11 commit-hook 2019-09-22 02:49:25 UTC
A commit references this bug: Author: gerald Date: Sun Sep 22 02:48:28 UTC 2019 New revision: 512547 URL: https://svnweb.freebsd.org/changeset/ports/512547 Log: Fix a miscompilation of GCC due to undefined behavior. This originally triggered when building with clang on amd64 (under some circumstances), but is a general issue. PR: 240387 Kudos to: dim (for first class detective work) Changes: head/lang/gcc10-devel/files/patch-pr240387
Comment 12 Gerald Pfeifer 2019-09-22 12:29:34 UTC
Thanks for your great work, dim@! Note: Likely I'll update this port to a snapshot with that fix in the coming days and remove the patch as part of that (since it's upstream already).
Comment 13 commit-hook 2019-09-25 14:23:25 UTC
A commit references this bug: Author: gerald Date: Wed Sep 25 14:22:40 UTC 2019 New revision: 512787 URL: https://svnweb.freebsd.org/changeset/ports/512787 Log: Update to the 20190922 snapshot of GCC 10.0.0. files/patch-pr240387 is part of that snapshot, so remove it on our end. PR: 240387 Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo head/lang/gcc10-devel/files/patch-pr240387