On Thu, Oct 1, 2015 at 2:08 AM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > After the shrink-wrapping patches the prologue will often be pushed > "deeper" into the function, which in turn means the software trace cache > pass will more often want to duplicate the basic block containing the > prologue. This caused failures for 32-bit SVR4 with -msecure-plt PIC. > > This configuration uses the load_toc_v4_PIC_1 instruction, which creates > assembler labels without using the normal machinery for that. If now > the compiler decides to duplicate the insn, it will emit the same label > twice. Boom. > > It isn't so easy to fix this to use labels the compiler knows about (let > alone test that properly). Instead, this patch wires up a "cannot_copy" > attribute to be used by TARGET_CANNOT_COPY_P, and sets that attribute on > these insns we do not want copied. > > Bootstrapped and tested on powerpc64-linux, with the usual configurations > (-m32,-m32/-mpowerpc64,-m64,-m64/-mlra); new testcase fails before, works > after (on 32-bit). > > Is this okay for mainline? > > > Segher > > > 2015-09-30 Segher Boessenkool <seg...@kernel.crashing.org> > > PR target/67788 > PR target/67789 > * config/rs6000/rs6000.c (TARGET_CANNOT_COPY_INSN_P): New. > (rs6000_cannot_copy_insn_p): New function. > * config/rs6000/rs6000.md (cannot_copy): New attribute. > (load_toc_v4_PIC_1_normal): Set cannot_copy. > (load_toc_v4_PIC_1_476): Ditto. > > gcc/testsuite/ > PR target/67788 > PR target/67789 > * gcc.target/powerpc/pr67789.c: New testcase.
Bernd mentions that this is the normal way of handling this problem, so okay. Thanks, David
