This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Let's kill specs, completely rewrite gcc.c
- To: Neil Booth <neilb at earthling dot net>
- Subject: Re: [RFC] Let's kill specs, completely rewrite gcc.c
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Sun, 7 Jan 2001 15:48:50 +0000 (GMT)
- cc: <gcc at gcc dot gnu dot org>, "Chris G . Demetriou" <cgd at sibyte dot com>
Would this also include a cleanup of the argument parsing in toplev.c and
lang_decode_option? 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 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.
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?
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 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"?)
--
Joseph S. Myers
jsm28@cam.ac.uk