This is an old thinko pertaining to the interaction between TLS sequences and
delay slot filling: the compiler knows that it cannot put instructions with
TLS relocations into delay slots with the original Sun TLS model, but it tests
TARGET_SUN_TLS in this context, which depends only on the assembler. So if
the compiler is configured with the GNU assembler and the Solaris linker, then
TARGET_GNU_TLS is set instead and the limitation is not enforced.
Tested on SPARC/Solaris and SPARC64/Linux, applied on all active branches.
2020-02-14 Eric Botcazou <ebotca...@adacore.com>
PR target/93704
* config/sparc/sparc.c (eligible_for_call_delay): Test HAVE_GNU_LD in
conjunction with TARGET_GNU_TLS in early return.
--
Eric Botcazou
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 7e05e1a6f82..aefced85fe1 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -3959,11 +3959,8 @@ eligible_for_call_delay (rtx_insn *trial)
if (get_attr_in_branch_delay (trial) == IN_BRANCH_DELAY_FALSE)
return 0;
- /* Binutils allows
- call __tls_get_addr, %tgd_call (foo)
- add %l7, %o0, %o0, %tgd_add (foo)
- while Sun as/ld does not. */
- if (TARGET_GNU_TLS || !TARGET_TLS)
+ /* The only problematic cases are TLS sequences with Sun as/ld. */
+ if ((TARGET_GNU_TLS && HAVE_GNU_LD) || !TARGET_TLS)
return 1;
pat = PATTERN (trial);