This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]