On Thu, Feb 11, 2016 at 04:14:59PM -0800, David Edelsohn wrote: > On Thu, Feb 11, 2016 at 1:43 PM, Michael Meissner > <meiss...@linux.vnet.ibm.com> wrote: > > After looking at Bernd Schmidt and Jakub Jelinek's suggestions, I came to > > conclusion that earlyclobber was not needed in this case, and I removed it. > > I > > bootstrapped the compiler using profiledbootstrap and lto options and it > > succeeded build and running make check. Just to be sure, I also did a > > profiledbootstrap with LTO and -O3 and it built fine. Is it ok to install > > these patches? > > > > I decided to keep the changes to the testsuite explicitly passing the fusion > > switches, rather than letting -mtune=power8/power9 set them, but I can be > > persuaded to restore the 3 tests to the way they were before February 9th. > > > > [gcc] > > 2016-02-11 Michael Meissner <meiss...@linux.vnet.ibm.com> > > > > PR target/68404 > > * config/rs6000/predicates.md (fusion_gpr_addis): Revert > > 2016-02-09 change. > > > > * config/rs6000/rs6000.md (fusion_gpr_load_<mode>): Remove > > earlyclobber from target. Use wF constraint for fused memory > > address. > > (fusion_gpr_<P:mode>_<GPR_FUSION:mode>_load): Likewise. > > > > [gcc/testsuites] > > 2016-02-11 Michael Meissner <meiss...@linux.vnet.ibm.com> > > > > PR target/68404 > > * gcc.target/powerpc/fusion.c: Do not assume that -mtune=power8 > > sets -mpower8-fusion or -mtune=power9 sets -mpower9-fusion. > > * gcc.target/powerpc/fusion2.c: Likewise. > > * gcc.target/powerpc/fusion3.c: Likewise. > > > > Since gcc 5.0 also has the earlyclobber in the pattern, I would like to > > apply > > the same change to gcc 5.x (after testing of course), even though we haven't > > yet run into the problem with GCC 5.x. Is this ok as well? > > This is okay for trunk and GCC 5 branch. > > Did you test the patch with the first patch reverted? The first patch > also was correct and fixed a problem, but it also allows this > underlying bug to appear more prominently. I want to ensure that the > patch was compared with a version of the compiler that elicited the > failure symptoms.
The patch to predicates.md reverts the original change that I made on February 9th. I did sync up the trunk to a newer revision, and I can go through a build without the rs6000.md patch to show that the rs6000.md patch is the one that fixes the problem if you prefer. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
