https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125418
--- Comment #17 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Matt Turner from comment #16)
> 1) GCC's own testsuite catches this. gcc.dg/tls/alpha-1.c is
>
> static __thread int xyzzy __attribute__ ((tls_model ("initial-exec")));
> int foo(void) { return xyzzy; }
> /* { dg-final { scan-assembler "gottprel" } } */
> /* { dg-final { scan-assembler-not "tprel(lo|hi|16)" } } */
>
> and it fails on trunk, because GCC emits !tprelhi/!tprello. This is
> dg-do compile, so no linker change can affect it. The test dates from the
> original TLS support and exists specifically to check that an explicit
> initial-exec is honored.
As H.J.Lu mentioned, the linker will not see the attribute and can upgrade
initial-exec to local-exec anyway. I don't see the point of "honoring" the
attribute in GCC without a clear rationale.
> 2) The attribute is discarded unconditionally, not only for hidden symbols.
> For a locally defined variable, all four tls_model values collapse to
> local-exec:
>
> static __thread int x __attribute__((tls_model("global-dynamic")));
> int foo(void) { return x; }
>
> $ gcc -fno-pie -S
> trunk: @tpoff (x86_64) !tprelhi (alpha)
> GCC 15: @tlsgd (x86_64)
>
> Same for local-dynamic and initial-exec. This particular case is harmless --
> local-exec is a valid implementation for a variable defined in a non-PIC
> executable -- but it shows the explicit attribute is being dropped outright
> rather than an optimization being applied where it happens to be safe.
I don't follow. GCC doesn't "drop" the attribute, it takes it and then upgrades
the TLS model exactly because it is safe (the linker is allowed to do the same
upgrade).
> I'll post a patch covering both front ends to gcc-patches.
Why? You already did it for the C front-end, and I think we came to an
agreement that the problem is with 'pragma weak' processing:
https://inbox.sourceware.org/gcc-patches/[email protected]/#t
Can you ping your latest patch from that thread?
