This is the mail archive of the gcc-patches@gcc.gnu.org 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: Using .opt files for target options


Richard Sandiford <rsandifo@redhat.com> writes:

> Zack Weinberg <zack@codesourcery.com> writes:
>> What target_flags_explicit does (assuming OVERRIDE_OPTIONS handles it)
>> is allow the user to not worry about the order of general and specific
>> -m options.  Really, what we want is to impose a partial ordering on
>> the -m options, so that general ones (-march= e.g.) are processed
>> before specific ones (-mgp64 e.g.)  I wonder if you have any ideas how
>> to handle that...?
>
> Well, I see target_flags_explicit as the target_flags equivalent
> of initialising a flag_foo variable to -1.  They're both ways of
> telling whether an option's state has been set explicitly.  I have
> to admit that I personally don't have a problem with either.
>
> Also, the current behaviour of the -m options is pretty easy to
> document at the user level: (1) they are processed left-to-right
> and (2) the default values of some options depend on other
> controllable properties, such as the selected architecture or ABI.
> A partial ordering sounds more like a multi-level thing.

Hoom, well, as long as you're willing to put up with the extra logic
in OVERRIDE_OPTIONS, I'm cool with this.  I have actually thought of 
a way to impose a partial ordering on the options, in such a way that
user-visible behavior does not change, but I don't know when if ever I
will have time to implement it, and it would qualify as a separate
cleanup anyway.  So, in summary, carry on. ;)

zw


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