On Sun, Jan 15, 2017 at 12:08:39AM +1030, Alan Modra wrote:
> On Sat, Jan 14, 2017 at 03:28:51AM -0600, Segher Boessenkool wrote:
> > On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> > > Bootstrapped and regression tested powerpc64-linux biarch. elf_high
> > > has said "Elf specific ways of loading addresses for non-PIC code"
> > > ^^^^^^^
> > > right from the inital V4 support in 1995.
> > >
> > > OK for mainline?
> >
> > Have you checked if/what this changes for some bigger code?
>
> Well, the bootstrap was all langs (minus ada due to not having ada
> installed) and ppc32 multilibs were built. Plus the testsuite run
> with RUNTESTFLAGS="--target_board=unix'{-m32,-m64}{-mlra,-mno-lra}'"
>
> I would have bootstrapped -m32 except the machine I used lacked 32-bit
> gmp, mpfr, mpc and I was lazy.
>
> > Okay for trunk if there is nothing unexpected. Thanks!
>
> I guess I should at least build glibc.
See Uros' comment about the INSN_CODE (insn) = insn_code_number;.
Also, I'm worried about it for another reason, after the
if (!targetm.legitimate_combined_insn (insn))
call the PATTERN is reverted to something different, so keeping INSN_CODE
equal to insn_code_number (which we sometimes even change to -1)
looks wrong, if it is the right thing to do it for the
legitimate_combined_insn call, it should be reverted afterwards when the
PATTERN changes again.
Or, perhaps instead of setting INSN_CODE, pass insn_code_number to the
target hook as another argument?
Jakub
