On 09/18/2014 01:36 PM, Richard Sandiford wrote: > Jakub Jelinek <ja...@redhat.com> writes: >> On Thu, Sep 18, 2014 at 12:04:30PM -0400, Vladimir Makarov wrote: >>> The following patch fixes the PR. The details can be found on >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 >>> >>> The patch was bootstrapped and tested on x86/x86-64. >>> >>> Committed as rev. 215358. >> What effect does this have on compile time? > Regardless of compile time, I strongly object to this kind of hack. > > (a) it will in practice never go away. > > (b) (more importantly) it makes no conceptual sense. It means that > passes before lra use the old, cached "enabled" attribute while > "lra" and after will uew "fresh" values. > > The only reason the call has been put here is because lra was the > only pass that checks for and asserted on inconsistent values. > Passes before lra will still see the same inconsistent values but > they happen not to assert. > > I.e. we've put the call here to shut up a valid assert rather than > because it's the right place to do it. > > (c) the "enabled" attribute was never supposed to be used in this way. > > I really think the patch should be reverted. > > Richard, I waited > 4 months that somebody fixes this in md file (and people tried to do this without success). Instead I was asked numerous times from people interesting in fixing these crashes to fix it in LRA. After a recent request, I gave up.
So I could revert it transferring blame on you but I don't think this hack is so bad to do this (may be I am wrong).
