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: [RFC] Use .opt for the SPARC port


> Here's the sort of thing I had in mind.  Does it look OK to you?
> I tested it by changing mips.opt to use the new record type and
> verifying that it had no effect on the options.h output.

The nice thing with my approach is that masks are almost like options, in 
particular you can put the same textual description in the .opt file.

> I agree about the consistency thing though.  It might be better to
> define _all_ target masks this way.  We could then remove the double
> meaning of Mask(...) property and also remove the slightly-controversial
> MaskExists thing.

I don't like this very much, because there would be 2 places to keep in sync 
for every option.  Self-contained option records are better I think.

So I propose the following compromise:

@item
A target mask record.  These records have three fields: the
string @samp{TargetMask}, a Mask(@var{name}) declaration and
an optional textual description.  The options-processing script will 
automatically allocate a unique bit in the @code{target_flags} variable
(@pxref{Run-time Target}) and set the macro @code{MASK_@var{name}} to the
appropriate bitmask.  It will also declare a @code{TARGET_@var{name}}
macro that has the value 1 when the option is active and 0 otherwise.
The textual description serves only as a comment.

> If this patch is OK, and if folks agree that it would be cleaner to
> define all masks in this way, I'll volunteer to change all the existing
> .opt files.

My proposition would save you from doing this. :-)

-- 
Eric Botcazou


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