[RFC] Fix PR 43574

[Jie Zhang]

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.


-- 
Jie Zhang
CodeSourcery
(650) 331-3385 x735