Hi! On Mon, Feb 11, 2019 at 11:08:12AM +1030, Alan Modra wrote: > On Fri, Feb 08, 2019 at 04:53:44PM -0600, Segher Boessenkool wrote: > > > @@ -37981,7 +37982,7 @@ rs6000_call_sysv (rtx value, rtx func_desc, rtx > > > tlsarg, rtx cookie) > > > func = rs6000_longcall_ref (func_desc, tlsarg); > > > /* If the longcall was implemented using PLT16 relocs, then r11 > > > needs to be valid at the call for lazy linking. */ > > > > This comment could use some work. > > True. I've rectified that and combined this patch with the > -mno-pltseq patch, documented as requested and enhanced to emit errors > and warnings when invalid options are combined. The two patches go > together, because someone building their ppc32 compiler with > --enable-secureplt but having old -mbss-plt relocatable objects on > their system will find that linking new -msecure-plt -mlongcall > objects against -mbss-plt objects will fail. One solution to that > problem is to compile with -mbss-plt whenever -mlongcall is needed, > but -mlongcall -mno-pltseq provides a way to transition everything to > -msecure-plt objects.
Okay. The best is much nicer now, thanks! > Bootstrapped and regression tested powerpc64le-linux and > powerpc64-linux biarch. I also built an rs6000-aix7.2 cross compiler > (well, cc1 and cc1plus, I don't have the aix headers to build libgcc) There are gcc111 and gcc119 in the cfarm. Bootstrap is slow, but --disable-bootstrap is okayish (but a bit fiddly). You could also just make a sysroot from them (no idea if that works, I haven't tried). > I'd also like to fix the formatting in linux64.h > SUBSUBTARGET_OVERRIDE_OPTIONS by moving all the continuation > backslashes one tab stop to the right when I commit this patch. Is > that OK too? I wonder if we could get rid of that completely? Use an inline function instead? Or a real function, shock horror. > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c > index b4ff18d414c..99f04bba148 100644 > --- a/gcc/config/rs6000/rs6000.c > +++ b/gcc/config/rs6000/rs6000.c > @@ -21665,7 +21665,7 @@ rs6000_indirect_call_template_1 (rtx *operands, > unsigned int funop, > || (REG_P (operands[funop]) > && REGNO (operands[funop]) == LR_REGNO)); > > - if (!TARGET_MACHO && HAVE_AS_PLTSEQ && GET_CODE (operands[funop]) == > UNSPEC) > + if (!TARGET_MACHO && TARGET_PLTSEQ && GET_CODE (operands[funop]) == UNSPEC) Does this need !TARGET_MACHO? That's implied by TARGET_PLTSEQ? > @@ -24834,6 +24835,11 @@ generate slower code. As of this writing, the AIX > linker can do this, > as can the GNU linker for PowerPC/64. It is planned to add this feature > to the GNU linker for 32-bit PowerPC systems as well. > > +On PowerPC64le and 32-bit PowerPC systems with newer GNU linkers, GCC The mixed capitalisation in "PowerPC64le" makes my head hurt. Luckily, what you really mean are PowerPC64 ELFv2 systems. Right? (Once more below). Okay for trunk, with those little tweaks (the inline thing is for another day of course). This was the last linker-related thing for GCC 9, right? Thanks, Segher
