Re: [RFC] Let's kill specs, completely rewrite gcc.c

[Neil Booth <neilb at earthling dot net>]

Joseph S. Myers wrote:-
> Would this also include a cleanup of the argument parsing in toplev.c and
> lang_decode_option?

No, this is the driver only.  It would be nice if the driver could
communicate more intelligently with the front ends, but I don't
immediately see how.

> It's absurd for C and C++ each to have their own long
> sequence of strcmps, when many options are common between them and
> toplev.c already includes a table W_options and code to use it for
> language-independent options.  (With slight complications of the tables to
> allow for functions to be called for specific options, all hardcoded
> conditionals on particular option names should be removable.)

I agree, though I don't immediately see a way to improve this.

> I presume this would fix the problem
> <URL:http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00545.html> that
> -funsigned-char -fsigned-char defines __CHAR_UNSIGNED__ but has
> signed char, which seems fairly intrinsic to the current specs
> scheme.

Maybe - I'm not familiar with that.  Specs aren't good at applying
logic, since they don't have the flexibility of a programming
language.  Hence why I want to do it in C via hooks :-)

> I also presume this would lead to a natural fix to c/545 (-std=c89 doesn't
> do the same as -ansi), although a kludge in some specs file could probably
> fix this in the present scheme?

Again, probably.

> Would the options -V and -b be removed (as seems plausible, if links by
> names such as gcc-3.0 to the driver get installed)?

I don't know.

> I think there should be a precise specification of the exact semantics of
> a series of command line options, some of which override each other.  For
> example, what is -fno-traditional supposed to mean?  (Specifying a
> language standard makes sense, though why it should override some previous
> options (e.g. -fwritable-strings - which does not stop an implementation
> from being conforming) but not others (e.g. -fcond-mismatch) doesn't.
> But what does it mean to specify "not traditional"?)

IIRC there's a lot of kludging in gcc.c to discover which of mutually
inconsistent options comes latest.  That could all be easily replaced,
too.  It could even be an automatic part of the
loop-through-each-switch-doing-a-binary-search-for-each too, if the
relevant switches are somehow flagged appropriately.

Neil.