[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #6 from Jakub Jelinek --- 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.
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #5 from Jakub Jelinek ---
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[0x1L];
__thread char c[32L];
int
foo (void)
{
return c[31L];
}
it just won't really link.
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #4 from Jakub Jelinek ---
char a;
__thread char b[0x8L];
int
foo (void)
{
return b[0x7L];
}
ICEs similarly with -O0 -fpie.
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- 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.
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- 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...
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621 Andrew Pinski 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 --- 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
