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

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Sun, 24 Jun 2001, Neil Booth wrote:

> I don't like that - there is a lot of duplication amongst options
> between front ends.  I don't seriously think we're in danger of
> running out of letters - we could even use printable chars if we had
> to.  Keeping things together is nicer IMO.

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.

> I don't see why it wouldn't work like any of the existing options
> work.  Which bit are you unsure of?

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).

> I'm not well versed in how this works at present.  But I don't see why
> it needs to be duplicated.  The driver could work off target macros,
> aand the front ends could use the macros and / or the target structure
> that is awaiting approval, depending upon where you want to do the
> check.

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.

-- 
Joseph S. Myers
jsm28@cam.ac.uk