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