This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [driver, LTO Patch]: Resurrect user specs support

On 05/28/2012 01:11 PM, Joseph S. Myers wrote:
> On Mon, 28 May 2012, Christian Bruel wrote:
>> I shared the same concern, however, after playing bits with spec toys, I
>> couldn't a find a way to get a %< switch recognition failure, since the
>> switches passed on the command line at this point are already validated
>> if necessary.
> Suppose with the existing sources an option (in a .opt file) is matched by 
> a $< spec, and not by any other spec.  Will it be rejected by the driver?  
> It shouldn't be. 

indeed, it's not rejected if it is present in a .opt file. I was
concerned that it will not be rejected even if not in any .opt (or now
in --specs). Which was what the validated setting seemed to imply.

Should it be rejected ? probably. But this is not implied by the --spec

 Are you saying there is some pre-existing bug here, or
> that %< validation happens in more than one place so some setting of 
> "validated" is redundant but the code still works correctly?

I think the check

 if (! switches[i].validated)

is already done when we process the do_spec for user specs.

It seems that there is no need to check for user option and set
'validated' in the cases '>:,'<', in do_spec_1 because if the switch
was not valid (not present in any .opt and not present in a user --spec)
it would already have been rejected.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]