This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fix PR 43574
On Tue, Mar 30, 2010 at 4:36 PM, Jie Zhang <jie@codesourcery.com> wrote:
> On 03/30/2010 09:37 PM, H.J. Lu wrote:
>>
>> On Tue, Mar 30, 2010 at 6:22 AM, Joseph S. Myers
>> <joseph@codesourcery.com> ?wrote:
>>>
>>> On Tue, 30 Mar 2010, H.J. Lu wrote:
>>>
>>>>> Well. ?I do not like the optimize attribute very much.
>>>>>
>>>>
>>>> I don't like it either. Its design is flawed and its implementation is
>>>> incomplete. I think it should be disabled and start it over. I have
>>>> some ideas:
>>>>
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
>>>
>>> My ideas are described at
>>> <http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> ?(which, although
>>> motivated by multilib issues, should as a side effect provide a global
>>> options structure helping to implement this attribute more reliably; see
>>> footnote 1 therein).
>>>
>>
>> I think multilib, which is file level compilation, ?and optimize
>> attribute,
>> which is function level compilation, are a little bit related, but more
>> orthogonal. In general, you don't need to save/restore flags for
>> file level compilation when compiling a single file. But you do need
>> to properly save/restore flags for function level compilation. This
>> has to be taken into account at infrastructure level.
>>
>> BTW, it will be nice to invoke cc1 once to compile multiple files
>> without gcc driver forks/execs cc1 multiple times. It can speed up
>> compilation.
>>
> It seems those are heavy hammers. Not needed for this PR, neither good for
> this stage of 4.5. The cause of PR43574 is simple. Since
> -fvar-tracking-assignments is in command line but -fvar-tracking is not
> (whether in command line or by calculation in process_options), both
> flag_var_tracking and flag_var_tracking_assignments are set to -1. But
> cl_optimization_save asserts they should be in the range of [0, 255]. Boom!
>
> At least there are two ways to fix them. One is my patch, which tells GCC
> the truth that these two flags might accept negative values. The other is
> suggested by Richard, which will modify these two options handling to ensure
> no <0 values will be used, such like use 3 instead of -1.
>
> Personally, I like the way my patch goes. Since (1) it has been done and
> tested; (2) "Signed" might be useful for other such flags in future. (3)
> Changing logic of these two flags seems more tricky.
I do not have a strong opinion against the Signed flag - the patch
is certainly technically ok. I am just not sure the reason to introduce
the flag is sound (and we're likely stuck with it once we introduce it).
Why not simply make all flags signed and adjust the assertion?
I doubt we have flags that have bigger values than 127.
Richard.
>
> --
> Jie Zhang
> CodeSourcery
> (650) 331-3385 x735
>