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:

> Switches for all front ends, and the driver, assembler, linker etc.,
> are listed in a single configuration file, "gcc.switches", below.
> Target-specific switches would be contained in an extra file in the
> relevant config/cpu directory.  These files are fairly free form, and
> so can be concatenated to get a complete switch definition file for a
> target.  The program "gen-switches" (below) takes such a file as
> input, an spits out a header file containing an "enum" for each switch
> group, and a ".tbl" file containing a hash table for the input
> switches.  So that, for example, the C front ends doesn't need to
> carry the baggage of Fortran and C++ switches, gen-switches can filter
> the switches and produce a hash table for specific front ends only.

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.

> words, we put all of "-fsigned-char", "-funsigned-char",
> "-fno-signed-char" and "-fno-unsigned-char" into a single group,
> called "GP_fsigned_char" say.  Another example of a suitable grouping
> is the three switches "-E", "-c" and "-S".  Each switch within a group

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?

> So, I propose we go with a scheme like the one described above.  It
> should be possible to extend it further.  For example, one thing I
> would like to do later is to move the --help documentation into the
> switch configuration file to go with each switch.  This would make it
> harder for people to add switches without documenting them :-) The
> driver could then print out most of the --help documentation in a
> loop.  Ultimately, it might even be possible to move the texinfo
> documentation into the configuration file, too.

Of course, you'd need to adapt exgettext to take help texts from the
switches file.  (But clearly the help texts ought to move there.)

Any moving of Texinfo documentation needs to take account of manpage
generation (which currently expects to work from a single source file) and
update_web_docs (which checks out .texi files but doesn't run configure or
build any .texi files not in CVS).

> Comments?

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

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