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

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

Joseph S. Myers wrote:-

> It might be better to keep the ability to drop in front ends by adding a
> subdirectory (without also patching the rest of GCC).  To do this you'd
> need the tables for front ends to be in separate files, for actual names
> such as {C++} and {Ada} to be used for front ends in the table rather than
> hard-coded single-letter codes (which I think would be a good idea anyway,
> to avoid limiting the number of front ends by the number of letters of the
> alphabet), and for compatible entries for a switch from different front
> ends to be merged.

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.

> Will this have the appropriate handling of both those cases: more than one
> of -E/-c/-S is an error, but the signed-char switches override each other?

At present I don't think it is an error.  But the point is that it's
easy to make the behaviour whatever you want.  If things are in the
same group, then they override, unless the group is chained.  So if
you wanted to give an error message for conflicting -E/-c/-S, just
leave them in separate groups and check that only one was specified in
the driver.

> How would --arch/--tune/--cpu-feature (following the scheme I suggested in
> http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01440.html) fit in with this
> system?  Would such files provide tables of the valid cpu-types and
> features for these options, and the old -m options be aliased (with a
> version of aliasing indicating a deprecation message should be produced)
> to them?

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

> I still want a clean scheme for ensuring that such macros as __SIZE_TYPE__
> and __INT_MAX__ always agree with the compiler's internal state, and this
> still duplicates some of this information in the specs-replacement, in the
> target headers and in <limits.h>.

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.

Neil.