David Edelsohn wrote: > On Mon, Sep 7, 2015 at 11:47 PM, Alan Modra <amo...@gmail.com> wrote: > > In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67378 analysis I show > > the reason for this PR is that insns emitted by secondary reload > > patterns are being generated without taking into account other reloads > > that may have occurred. We run into this problem when an insn has a > > pseudo that doesn't get a hard reg, and the pseudo is used in a way > > that requires a secondary reload. In this case the secondary reload > > is needed due to gcc generating a 64-bit gpr load from memory insn > > with an address offset not a multiple of 4. > > > > Bootstrapped and regression tested powerpc64-linux. OK to apply? > > gcc-5 and gcc-4.9 branches too? > > > > I haven't included a testcase in this patch, because the testcase in > > the PR is quite horrible, and testcases triggering reload misbehaviour > > tend to be unreliable. By unreliable, I mean a small change anywhere > > in the compiler can result in the testcase passing even if this bug > > was reintroduced at some future date. The testcase doesn't fail on > > gcc-5, even though I'm fairly sure the same bug lurks there.. > > > > PR target/67378 > > * config/rs6000/rs6000.c (rs6000_secondary_reload_gpr): Find > > reload replacement for PRE_MODIFY address reg. > > I'm okay with this patch, but I'd like Uli to double-check it when he > has a moment.
The patch looks OK to me. We definitely need to check for replacements in secondary reload in such cases. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
