Bug 87780 - [9 regression] ICE error: unrecognizable insn
Summary: [9 regression] ICE error: unrecognizable insn
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 9.0
: P3 normal
Target Milestone: 9.0
Assignee: Segher Boessenkool
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-28 23:40 UTC by Romain Geissler
Modified: 2018-10-29 17:06 UTC (History)
1 user (show)

See Also:
Host:
Target: x86_64-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-10-29 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Geissler 2018-10-28 23:40:28 UTC
Hi,

I have the following ICE when building llvm+clang+lld 7.0.0 (PGO + LTO profile) on x64 with gcc from 28/10/2018 (while it was working fine with gcc from 11/10/2018):

/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h:5222:1: error: unrecognizable insn:
 5222 | }
      | ^
(insn 1262 1261 1263 2 (set (reg:V1TI 678)
        (reg:TI 1 dx [ TL ])) "/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h":5212:1 -1
     (nil))
during RTL pass: subreg2
/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h:5222:1: internal compiler error: in extract_insn, at recog.c:2305
0xfb86cb ???
	/workdir/src/gcc-9.0.0/gcc/rtl-error.c:108
0xfb86e7 ???
	/workdir/src/gcc-9.0.0/gcc/rtl-error.c:116
0x90ac09 ???
	/workdir/src/gcc-9.0.0/gcc/recog.c:2305
0x179be75 ???
	/workdir/src/gcc-9.0.0/gcc/lower-subreg.c:1483
0x180b49d ???
	/workdir/src/gcc-9.0.0/gcc/lower-subreg.c:1750
0x12750d6 ???
	/workdir/src/gcc-9.0.0/gcc/passes.c:2428
0x12e9abc ???
	/workdir/src/gcc-9.0.0/gcc/passes.c:2517
0x14dd528 ???
	/workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2194
0x12727ca ???
	/workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2332
0x1268677 ???
	/workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2861
0x1240f3a ???
	/workdir/src/gcc-9.0.0/gcc/toplev.c:480
0x11b05c6 ???
	/workdir/src/gcc-9.0.0/gcc/toplev.c:2172
0x11af92a ???
	/workdir/src/gcc-9.0.0/gcc/main.c:39
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
ninja: build stopped: subcommand failed.

Cheers,
Romain
Comment 1 Andrew Pinski 2018-10-29 00:55:02 UTC
Can you attach the preprocessed source?  Or reduce it as it is PGO/LTO.
Also it seems like a missing subreg.
Comment 2 Segher Boessenkool 2018-10-29 07:14:19 UTC
Mine.
Comment 3 Segher Boessenkool 2018-10-29 07:37:17 UTC
Author: segher
Date: Mon Oct 29 07:36:45 2018
New Revision: 265582

URL: https://gcc.gnu.org/viewcvs?rev=265582&root=gcc&view=rev
Log:
combine: Fix various shortcomings in make_more_copies (PR87701, PR87780)

This rewrites most of make_more_copies, in the process fixing a few PRs
and some other bugs, and working around a few target problems.  Certain
notes turn out to actually change the meaning of the RTL, so we cannot
drop them; and i386 takes subregs of hard regs.


	PR rtl-optimization/87701
	PR rtl-optimization/87780
	* combine.c (make_more_copies): Rewrite.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/combine.c
Comment 4 Segher Boessenkool 2018-10-29 07:39:56 UTC
Fixed.
Comment 5 Romain Geissler 2018-10-29 13:59:38 UTC
Hi,

Trying with today's trunk with this patch included, my clang PGO+LTO bootstrap goes further, but then the generated clang fails to compile itself. Just putting here the clang error for reference:

fatal error: error in backend: Cannot select: 0x20c13f8: ch = fp_to_fp16 0x201f1d8, 0x20bccd8, FrameIndex:i64<0>
  0x20bccd8: f80,ch = CopyFromReg 0x201f1d8, Register:f80 %0
    0x20bcc08: f80 = Register %0
  0x20c1bb0: i64 = FrameIndex<0>
In function: __divtc3
clang-7: error: clang frontend command failed with exit code 70 (use -v to see invocation)

The only thing that I changed recently is binutils/gcc/glibc, not the clang sources. So there might still have some code gen issue left in gcc trunk (which I don't know how to investigate).

Cheers,
Romain
Comment 6 Segher Boessenkool 2018-10-29 17:06:49 UTC
That sounds like a clang problem; without more information, anyway.