Re: [RFC] Suggested replacement for specs and switch handling

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Joseph S. Myers wrote:-

> I think it's nicer for front ends to be able to be separate.  We want it
> to be possible, in principle, for a separate front end not to have a tight
> version dependency on the rest of GCC, but just to be able to have the
> subdirectories added and work, if it uses the documented interfaces.  If
> it needs a patch to a central options file, such a patch is bound to
> conflict with changes to the central file between releases.

Hmm.  We're a long way from that at present.  In taking out the option
strings from GCC, I think the patch goes a bit further down that path.
I agree what you're saying would be nice, however I don't want to make
the switch handling more complicated than it needs to be to just get
it working.  Once we have it working, it shouldn't be too hard to
split things out.  Not just now, though, please :-)

> What I'd proposed had --cpu-feature=foo,no-bar,baz and it doesn't seem
> clear to me where that form of option would fit in - if we allow foo,bar
> in a single option but want the --help text to list all features
> available.  Also, aesthetically, the CPU names valid for --arch and --tune
> should be listed just once in --help output (with each name being valid
> for both).

Yes, documentation needs more thought because of this and other
issues; I just intended to point out that we should be able to put the
documentation in the same place in theory.

> At present, the driver uses specs, and the compiler's state uses
> definitions evaluating to such things as (TARGET_64BIT ? 64 : 32).  The
> way the options interact to determine values such as LONG_TYPE_SIZE needs
> to appear in just one place, which then drives macros such as
> __LONG_MAX__.  (And <limits.h> uses a mess of definitions that in order to 
> work properly really need to be replaced by the compiler defining, 
> unconditionally, __SCHAR_MAX__, __SHRT_MAX__, __INT_MAX__, __LONG_MAX__ 
> and __LONG_LONG_MAX__.)  The information such as TARGET_64BIT currently 
> uses variables in the back end.

I suggest we put most of the macro definition logic in the driver (for
things that apply to all targets), and the rest in the target-specific
file linked into the driver.  That would avoid unnecessary
duplication.  I don't see that the current situation, where some
define it and some don't, and cpplib picks up the pieces with #ifdef
is a good thing.

In fact, with this scheme of switch handling the driver should be able
to handle various things that are currently handled in front ends,
toplev.c, or elsewhere.

Neil.