The issue is that I cannot reproduce it on the official released branches. It happens on my local GCC branch (with a new port). Let's see if the original author of the patch has an testcase. Zhenqiang, do you have one that can reproduce this bug with the official 4.8/4.9 branches? Thanks. Cheers, Felix
On Thu, Oct 9, 2014 at 6:41 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Oct 9, 2014 at 11:35 AM, Yangfei (Felix) <felix.y...@huawei.com> > wrote: >> >>> > > > On Thu, Oct 09, 2014 at 09:04:49AM +0000, Yangfei (Felix) wrote: >>> > > > > On Wed, Oct 08, 2014 at 11:00:24PM +0800, Felix Yang wrote: >>> > > > > The enclosed patch for 4.8 & 4.9 branch is a backport of r211885 >>> > > > > from >>> > trunk. >>> > > > > >>> > > > > The only change is to use: >>> > > > > >>> > > > > for (def_rec = DF_INSN_INFO_DEFS (insn_info); *def_rec; >>> > > > > def_rec++) >>> > > > > >>> > > > > other than the new FOR_EACH_INSN_INFO_DEF interface. >>> > > > > >>> > > > > Bootstrapped on x86_64-SUSE-Linux for both branches. OK to apply? >>> > > > >>> > > > ChangeLog entry is missing, plus description why do you want to >>> > > > backport >>> > it. >>> > > > If it fixes a bug on the branches, it would be better to have a >>> > > > bugzilla PR for that, and definitely a testcase. >>> > > > >>> > > >>> > > Yeah, I will add a ChangeLog entry for this patch when it is committed. >>> > > I encountered the same issue when working on my local customized >>> > > 4.8/4.9 >>> > branches. Not reproduceable with the official 4.8/4.9 branches. >>> > > I thinks it's just an enhancement for the loop invariant pass to >>> > > make it more >>> > versatile. It's better that 4.8/4.9 branches also inlcude this >>> > enhancement. >>> > > OK? >>> > >>> > If it is just an enhancement, then those generally are not backported >>> > to release branches (exceptions possible of course, but there needs to be >>> > a >>> strong reason). >>> > Each pass has some risk of breaking something, exposing previously >>> > only latent bugs in later passes etc. >>> > >>> > Jakub >>> >>> We can treat it as bugfix, as we got incorrect code when it triggers. >>> It just happens so rarely. Does it worth backporting? >> >> And the patch fix this bug by making the loop invariant pass more >> conservative. >> I didn't find a PR or testcase on trunk for this patch either. > > We at least want a testcase for the "we got incorrect code when it triggers". > > Richard. > >>
