Bug 240387 - lang/gcc10-devel, 20190901 snapshot: internal compiler error: Segmentation fault
Summary: lang/gcc10-devel, 20190901 snapshot: internal compiler error: Segmentation fault
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-07 11:17 UTC by Dimitry Andric
Modified: 2019-09-25 14:23 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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. [1]

  PR:		240387 [1]

Changes:
  head/lang/gcc10-devel/Makefile
  head/lang/gcc10-devel/distinfo
Comment 4 Dimitry Andric freebsd_committer 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 freebsd_committer 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 freebsd_committer 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  <rguenther@suse.de>

            * 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 freebsd_committer 2019-09-13 20:18:27 UTC
Submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767
Comment 8 Dimitry Andric freebsd_committer 2019-09-20 09:02:04 UTC
Upstream fix: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=275989
Comment 9 Dimitry Andric freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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