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. Thanks, David
