On Mon, Nov 11, 2019 at 05:56:47AM -0600, Segher Boessenkool wrote: > On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote: > > 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. > > Okay. > > > (rs6000_call_template_1): Delete TARGET_TLS_MARKERS test and > > allow other UNSPECs besides UNSPEC_TLSGD and UNSPEC_TLSLD. > > Why is that? Should we allow the other code that can happen and keep > the gcc_unreachable? Or do we know that no other code can happen here > ever, and the extra documentation isn't useful?
The code in question is just printing the @tlsgd or @tlsld arg. I don't see any point in asserting that no other UNSPEC could ever be used in a call operand. Other places dealing with UNSPEC_TLSGD and UNSPEC_TLSLD don't check, and if another UNSPEC is invented for some fancy future call insn it's quite unlikely to want to output anything here. (I don't think I found such an UNSPEC already extant..) > > --- a/gcc/config/rs6000/rs6000.md > > +++ b/gcc/config/rs6000/rs6000.md > > @@ -9413,7 +9413,7 @@ (define_insn_and_split "*tls_gd<bits>" > > (unspec:P [(match_operand:P 1 "rs6000_tls_symbol_ref" "") > > (match_operand:P 2 "gpc_reg_operand" "b")] > > UNSPEC_TLSGD))] > > - "HAVE_AS_TLS && TARGET_TLS_MARKERS" > > + "HAVE_AS_TLS && !TARGET_XCOFF" > > Should that be TARGET_ELF instead? Either should work. So, yes, probably better with TARGET_ELF. -- Alan Modra Australia Development Lab, IBM
