Patch to fix PR61360

Vladimir Makarov vmakarov@redhat.com
Thu Sep 18 18:10:00 GMT 2014


On 09/18/2014 01:36 PM, Richard Sandiford wrote:
> Jakub Jelinek <jakub@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).





More information about the Gcc-patches mailing list