public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: PC-relative TLS support
Date: Mon, 11 Nov 2019 07:40:00 -0000	[thread overview]
Message-ID: <20191111071600.GA30058@bubble.grove.modra.org> (raw)
In-Reply-To: <20190821122528.GC9455@bubble.grove.modra.org>

On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> On Mon, Aug 19, 2019 at 07:45:19AM -0500, Segher Boessenkool wrote:
> > But if you think we can remove the !TARGET_TLS_MARKERS everywhere it
> > is relevant at all, now is the time, patches very welcome, it would be
> > a nice cleanup :-)  Needs testing everywhere of course, but now is
> > stage 1 :-)
> 
> This patch removes !TARGET_TLS_MARKERS support.  -mtls-markers (and
> -mno-tls-markers) disappear as valid options too, because I figure
> they haven't been used too much except by people testing the
> compiler.  Bootstrapped and regression tested powerpc64le-linux and
> powerpc-ibm-aix7.1.3.0 (on gcc111).  I believe powerpc*-darwin doesn't
> support TLS.
> 
> Requiring an 8 year old binutils-2.20 shouldn't be that onerous.
> 
> Note that this patch doesn't remove the configure test to set
> HAVE_AS_TLS_MARKERS.  I was wondering whether I ought to hook that
> into a "sorry, your assembler is too old" error?

https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01487.html

I should have pinged this before now, and really I think the following
additional patch makes more sense than any sort of sorry message.
Mostly people will be running the assembler anyway so will discover
quickly that their assembler is too old.

	* configure.ac (HAVE_AS_TLS_MARKERS): Delete test.
	* configure: Regenerate.
	* config.in: Regenerate.

diff --git a/gcc/configure.ac b/gcc/configure.ac
index 5f32fd4d5e4..44d816630e9 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4811,12 +4811,6 @@ LCF0:
       [AC_DEFINE(HAVE_AS_GNU_ATTRIBUTE, 1,
 	  [Define if your assembler supports .gnu_attribute.])])
 
-    gcc_GAS_CHECK_FEATURE([tls marker support],
-      gcc_cv_as_powerpc_tls_markers, [2,20,0],,
-      [ bl __tls_get_addr(x@tlsgd)],,
-      [AC_DEFINE(HAVE_AS_TLS_MARKERS, 1,
-	  [Define if your assembler supports arg info for __tls_get_addr.])])
-
     gcc_GAS_CHECK_FEATURE([prologue entry point marker support],
       gcc_cv_as_powerpc_entry_markers, [2,26,0],-a64 --fatal-warnings,
       [ .reloc .,R_PPC64_ENTRY; nop],,

> 	* config/rs6000/rs6000-protos.h (rs6000_output_tlsargs): Delete.
> 	* config/rs6000/rs6000.c (rs6000_output_tlsargs): Delete.
> 	(rs6000_legitimize_tls_address): Remove !TARGET_TLS_MARKERS code.
> 	(rs6000_call_template_1): Delete TARGET_TLS_MARKERS test and
> 	allow other UNSPECs besides UNSPEC_TLSGD and UNSPEC_TLSLD.
> 	(rs6000_indirect_call_template_1): Likewise.
> 	(rs6000_pltseq_template): Likewise.
> 	(rs6000_opt_vars): Remove "tls-markers" entry.
> 	* config/rs6000/rs6000.h (TARGET_TLS_MARKERS): Don't define.
> 	(IS_NOMARK_TLSGETADDR): Likewise.
> 	* config/rs6000/rs6000.md (tls_gd<bits>): Replace TARGET_TLS_MARKERS
> 	with !TARGET_XCOFF.
> 	(tls_gd_high<bits>, tls_gd_low<bits>): Likewise.
> 	(tls_ld<bits>, tls_ld_high<bits>, tls_ld_low<bits>): Likewise.
> 	(pltseq_plt_pcrel<mode>): Likewise.
> 	(call_value_local32): Remove IS_NOMARK_TLSGETADDR predicate test.
> 	(call_value_local64): Likewise.
> 	(call_value_indirect_nonlocal_sysv<mode>): Remove IS_NOMARK_TLSGETADDR
> 	output and length attribute sub-expression.
> 	(call_value_nonlocal_sysv<mode>),
> 	(call_value_nonlocal_sysv_secure<mode>),
> 	(call_value_local_aix<mode>, call_value_nonlocal_aix<mode>),
> 	(call_value_indirect_aix<mode>, call_value_indirect_elfv2<mode>),
> 	(call_value_indirect_pcrel<mode>): Likewise.
> 	* config/rs6000/rs6000.opt (mtls-markers): Delete.
> 	* doc/install.texi (powerpc-*-*): Require binutils-2.20.

-- 
Alan Modra
Australia Development Lab, IBM

  reply	other threads:[~2019-11-11  7:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 21:36 PowerPC 'future' patches introduction Michael Meissner
2019-08-14 21:37 ` [PATCH], Patch #1 of 10, Add instruction format enumeration Michael Meissner
2019-08-14 22:11 ` [PATCH], Patch #2 of 10, Add RTL prefixed attribute Michael Meissner
2019-08-19 19:15   ` Segher Boessenkool
2019-08-14 22:12 ` [PATCH], Patch #3 of 10, Add prefixed addressing support Michael Meissner
2019-08-16  1:59   ` Bill Schmidt
2019-08-14 22:15 ` [PATCH], Patch #4 of 10, Adjust costs based on insn sizes Michael Meissner
2019-08-14 22:23 ` [PATCH], Patch #5 of 10, Make -mpcrel default for -mcpu=future Michael Meissner
2019-08-14 23:10 ` [PATCH], Patch #6 of 10, Add 'future' support to function attributes Michael Meissner
2019-08-14 23:13 ` [PATCH], Patch #7 of 10, Add support for PCREL_OPT Michael Meissner
2019-08-14 23:16 ` [PATCH], Patch #8 of 10, Miscellaneous future tests Michael Meissner
2019-08-14 23:17 ` [PATCH], Patch #9 of 10, Add tests with large memory offsets Michael Meissner
2019-08-15  3:48 ` [PATCH], Patch #10 of 10, Add pc-relative tests Michael Meissner
2019-08-15  4:05 ` PowerPC 'future' patches introduction Segher Boessenkool
2019-08-15  8:10 ` PC-relative TLS support Alan Modra
2019-08-15 19:47   ` Segher Boessenkool
2019-08-16  4:09     ` Alan Modra
2019-08-19 13:39       ` Segher Boessenkool
2019-08-21 13:34         ` Alan Modra
2019-11-11  7:40           ` Alan Modra [this message]
2019-11-11 11:45             ` Segher Boessenkool
2019-11-11 12:10           ` Segher Boessenkool
2019-11-11 13:36             ` Alan Modra
2019-08-15 21:35 ` [PATCH], Patch #1 replacement (fix issues with future TLS patches) Michael Meissner
2019-08-16  0:25   ` Segher Boessenkool
2019-08-16  0:42   ` Bill Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191111071600.GA30058@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).