On Tue, 18 Nov 2014, Tom de Vries wrote: > Richard, > > this (trunk) patch fixes PR62167. > > The patch fixes a problem that triggers with the test-case on the 4.8 branch, > when tail-merge makes a dead type-unsafe load alive. > > I'm not able to reproduce this bug on 4.9 and trunk with the same test-case. > On those branches, the tail-merge already does not happen. > > The reason for the difference is as follows: With 4.8 the two phi arguments of > the phi in the tail block are value-numbered identically: > ... > SCC consists of: p_14 > Value numbering p_14 stmt = p_14 = MEM[(struct head *)_13].first; > Setting value number of p_14 to p_14 (changed) > > SCC consists of: p_15 > Value numbering p_15 stmt = p_15 = _13->next; > Setting value number of p_15 to p_14 (changed) > ... > > With 4.9 (and trunk), that's not the case: > ... > SCC consists of: p_14 > Value numbering p_14 stmt = p_14 = MEM[(struct head *)&heads][k.1_9].first; > Setting value number of p_14 to p_14 (changed) > > SCC consists of: p_15 > Value numbering p_15 stmt = p_15 = _13->next; > Setting value number of p_15 to p_15 (changed) > ... > > I'm not sure the bug triggers on trunk and 4.9, but I see no reason why it > could not trigger, so I'd prefer to apply the patch to 4.9 and trunk as well. > > The patch introduces an xfail for pr51879-12.c. I can follow up with a patch > to improve upon that, but I think that's better limited to trunk only.
Yeah. > Bootstrapped and reg-tested on x86_64/trunk. > > OK for trunk/stage3, 4.8, 4.9? Ok. Note that this goes well with disabling the (re-)use of value-numbering in tail-merging (which causes me quite some headaches...). On trunk it shouldn't be necessary as much as it was earlier as we now fully propagate constants and copies during FRE/PRE elimination. Thanks, Richard.