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. [1]

  PR:		240387 [1]

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  <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 2019-09-13 20:18:27 UTC

Submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767

Comment 8 Dimitry Andric 2019-09-20 09:02:04 UTC

Upstream fix: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=275989

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