Convert options to array of cl_decoded_option structures

[Manuel López-Ibáñez]

On 18 June 2010 13:13, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Fri, 18 Jun 2010, Manuel López-Ibáñez wrote:
>
>> On 18 June 2010 12:16, Joseph S. Myers <joseph@codesourcery.com> wrote:
>> > +       case OPT_Ofast:
>> > +         /* -Ofast only adds flags to -O3.  */
>> > +         optimize_size = 0;
>> > +         optimize = 3;
>> > +         ofast = 1;
>> > +         break;
>>
>> I believe that the original idea was that commandline options should
>> enable other options by simulating that they appeared in the command
>> line. That is the purpose of the new handle_option and how it is done
>> for Wimplicit. Has the plan changed now? Or are you planning to do
>> this in a follow-up patch?

> I should point out that I don't really think of -Ofast as implying -O3 in
> the normal sense of option implications.  Rather, I think of -O as more
> like an option with enumerated arguments (1, 2, 3, s, fast), where no
> argument is an alias for 1 and arguments that are integers greater than 3
> are aliases for 3; logically, you'd take the value of that enumeration
> from the last -O option present, and only then convert that value into the
> settings of multiple variables.  I *do* expect to implement some generic
> support for options with enumerated arguments in this patch series - there
> are so many instances of ad hoc code for such options at present - but it
> probably won't cover the special case of -O, just the more normal cases
> such as -march where there is a clear limited finite set of arguments.

OK, I misunderstood that cleaning up the options that enable other
options was part of your goals. In general, for options implying other
options (which seems is not the case of -Ofast and I misunderstood
your patch), should we start using handle_option or only when that
fixes a reported bug like in the Wimplicit case?

Manuel.