public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
@ 2024-04-06 19:26 zsojka at seznam dot cz
2024-04-06 19:36 ` [Bug target/114621] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: zsojka at seznam dot cz @ 2024-04-06 19:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Bug ID: 114621
Summary: ICE: in extract_insn, at recog.cc:2812 (unrecognizable
insn) with -O -fpie and _Thread_local with large
offset
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57893&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fpie testcase.c
testcase.c: In function 'foo':
testcase.c:8:1: error: unrecognizable insn:
8 | }
| ^
(insn 6 5 7 2 (set (reg:DI 106)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("b") [flags 0x2a] <var_decl
0x7f8995010cf0 b>)
] UNSPEC_NTPOFF)
(const_int 34359738367 [0x7ffffffff])))) "testcase.c":7:10 -1
(nil))
during RTL pass: vregs
testcase.c:8:1: internal compiler error: in extract_insn, at recog.cc:2812
0x80873f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x8087bc _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x7f762b extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2812
0x11329cd instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1612
0x11329cd instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1995
0x11329cd execute
/repo/gcc-trunk/gcc/function.cc:2042
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9803-20240405111321-g9ab8fdfeef5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9803-20240405111321-g9ab8fdfeef5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240405 (experimental) (GCC)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
@ 2024-04-06 19:36 ` pinskia at gcc dot gnu.org
2024-04-08 8:04 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-06 19:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.6.4
Summary|ICE: in extract_insn, at |[11/12/13/14 Regression]
|recog.cc:2812 |ICE: in extract_insn, at
|(unrecognizable insn) with |recog.cc:2812
|-O -fpie and _Thread_local |(unrecognizable insn) with
|with large offset |-O -fpie and _Thread_local
| |with large offset
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-04-06
Target Milestone|--- |11.5
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This didn't ICE in GCC 4.5.4 but it produced assembly which would almost
definitely not link:
movzbl 34359738367+b@tpoff(%rax), %eax
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
2024-04-06 19:36 ` [Bug target/114621] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
@ 2024-04-08 8:04 ` jakub at gcc dot gnu.org
2024-04-08 8:24 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-08 8:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the ICE started with
r0-105763-g42a48c4fd679d11d10d19d6986c44f7c6dbb57dd
The old emitted asm certainly assembled and I don't see why it wouldn't link,
yes, it is UB at runtime...
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
2024-04-06 19:36 ` [Bug target/114621] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
2024-04-08 8:04 ` jakub at gcc dot gnu.org
@ 2024-04-08 8:24 ` jakub at gcc dot gnu.org
2024-04-08 17:36 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-08 8:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uros at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But I'm quite lost where ix86_legitimize_address should fix this up.
It e.g. calls
12829 if (changed && ix86_legitimate_address_p (mode, x, false))
12830 return x;
but ix86_legitimate_address_p returns false there, but it still doesn't fix it
up later and just returns x anyway.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
` (2 preceding siblings ...)
2024-04-08 8:24 ` jakub at gcc dot gnu.org
@ 2024-04-08 17:36 ` jakub at gcc dot gnu.org
2024-04-08 18:06 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-08 17:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
char a;
__thread char b[0x800000000L];
int
foo (void)
{
return b[0x7ffffffffL];
}
ICEs similarly with -O0 -fpie.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
` (3 preceding siblings ...)
2024-04-08 17:36 ` jakub at gcc dot gnu.org
@ 2024-04-08 18:06 ` jakub at gcc dot gnu.org
2024-04-12 13:34 ` law at gcc dot gnu.org
2024-04-12 13:38 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-08 18:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
While for the local exec we happily use something like
movq %fs:0, %rax
movabsq $b@tpoff+34359738367, %rdx
addq %rdx, %rax
movzbl (%rax), %eax
we normally use instructions like
movsbl %fs:b@tpoff+31, %eax
Thus, I'd say at least in the normal code models we have a restriction that the
static TLS area of the whole program must fit into 2GB.
If we want to support something larger, we'd need to use 64-bit relocations
consistently for all LE/IE accesses regardless of whether the immediate offset
into them is > 2GB or not, because it could just be that some other library has
the static TLS area > 2GB and comes earlier, or some other TU etc.
x86-64 has both R_X86_64_TPOFF32 and R_X86_64_TPOFF64 relocations, but it
wouldn't help if we use the 32-bit ones in say
char a;
__thread char b[0x100000000L];
__thread char c[32L];
int
foo (void)
{
return c[31L];
}
it just won't really link.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
` (4 preceding siblings ...)
2024-04-08 18:06 ` jakub at gcc dot gnu.org
@ 2024-04-12 13:34 ` law at gcc dot gnu.org
2024-04-12 13:38 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: law at gcc dot gnu.org @ 2024-04-12 13:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
CC| |law at gcc dot gnu.org
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
` (5 preceding siblings ...)
2024-04-12 13:34 ` law at gcc dot gnu.org
@ 2024-04-12 13:38 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-12 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P2
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
A 13 years old ICE on an obscure testcase isn't P1, nobody is using hundreds of
megabytes of TLS data, typically one uses hundreds of bytes at most, these
problems are only when one needs more than 2GB of TLS data.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-04-12 13:38 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-06 19:26 [Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset zsojka at seznam dot cz
2024-04-06 19:36 ` [Bug target/114621] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
2024-04-08 8:04 ` jakub at gcc dot gnu.org
2024-04-08 8:24 ` jakub at gcc dot gnu.org
2024-04-08 17:36 ` jakub at gcc dot gnu.org
2024-04-08 18:06 ` jakub at gcc dot gnu.org
2024-04-12 13:34 ` law at gcc dot gnu.org
2024-04-12 13:38 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).