[Bug target/114621] New: ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset

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

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)

[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

[pinskia at gcc dot gnu.org]

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

[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

[jakub at gcc dot gnu.org]

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...

[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

[jakub at gcc dot gnu.org]

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.

[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

[jakub at gcc dot gnu.org]

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.

[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

[jakub at gcc dot gnu.org]

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.

[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

[law at gcc dot gnu.org]

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

[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

[jakub at gcc dot gnu.org]

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.