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

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

[Neil Booth]

Over the last 3 months, changes to cpplib have required updating the
SPECS handling in gcc.c.  For example, to fix the meaning of '|', and
to preserve order of -D and -U on the command line.  I think yet
another spec may be required, similar to what Nathan posted last week,
for me to handle -MD and -MMD correctly - path preservation but suffix
replacement.

A few mails last November with Chris Demetriou inspired me to think of
better way of doing things.  It strikes me that most patches to gcc.c
are simply kludges on top of an already gross kludge, and that the
spec-parsing part of gcc.c is hard to follow.  However, I don't know
the historical reasons for specs being the way they are, so I may be
missing something.

Other reasons to replace specs:-

a) They are grossly inefficient.  For example, the common SPEC for CPP
contains 50 sub-specs now.  Each of these sub-specs requires a
complete scan of every command-line option.  This amounts to an
enormous amount of strcmps, when you have an average of 15 to 20
command line options.  And that's just the common spec for CPP - it
doesn't include the additional target-specific CPP specs, or the specs
of the other "compilers", or that every command line option goes
through another 20 or so strcmps for gcc.c special things like
"-print-file-name", "-ftarget-help", and maybe yet more for option
remapping etc.

b) They are inflexible - most processing needs to be expressed in
terms of specs formulae, or kludged some other way.  I'm thinking of
things like pipe handling, preserving -U and -D ordering, "GNU C does
not support -C without using -E" error messages etc. here.  Another
good example here is that cpplib accepts a whole host of options that
tradcpp doesn't, e.g. -ftabstop=, but we have no way of telling "gcc"
to pass them on to cpplib but not to tradcpp that isn't ridiculously
convoluted.  If you need one more, we pass the -W options on to CPP as
{W*}.  In order for this to work, CPP has to be coded to silently
accept -W options that it doesn't understand.  It would be nice if CPP
could give an error instead.

c) Chris said they make target or processor-specific configuration in
the config/* files awkward in some cases.  I'm no expert, so I'll take
his word for that :-)

I would like to suggest a different approach, along the following
rough lines:

1) gcc.c contains a sorted table of all command-line options that compilers
   it drives understands.  This might need to be provided by a separate
   ".tab" file generated at compile time and #included into gcc.c, for
   reasons of flexibility over front-ends.

2) each switch in the table is flagged for such things as which front-ends
   understand it, whether it takes an appended argument, a separate
   argument, or both, etc.

3) for each command line switch, gcc.c uses this information to do a binary
   search in the table for that switch.  It extracts any argument as
   appropriate.  [code to do this with slightly less generality
   already exists in cppinit.c]

4) Each possible switch has a usage count.  During stage 3, this is
   incremented as the command line is scanned.  Also, each command-line
   argument is flagged with which front-ends understand it, and whether
   it is a switch or argument, etc.

5) gcc.c works out which compiler chain is needed to perform the compilation,
   much as it does now from file extensions.  Virtualization through
   hooks might be needed here.

6) With 4) and 5), any redundant or unused switches are easily scanned
   for in a single pass and complained about.

7) Each compiler has a hook, and it is passed the flagged command-line
   argument list from 4).  This, and the usage counts in 4), makes it
   easy to do cleanly extra processing of the kind currently handled
   by specs like

   %{ffast-math:-D__FAST_MATH__}
   %{MMD:-MM -MF %b.d}

   At the same time, the compiler-specific hook extracts all the
   switches flagged for use by its compiler, builds the relevant
   command line, and invokes its compiler.

I believe the above scheme (where a few details are omitted),
encapsulates the full functionality provided by specs at present, and
with the hooks provides more useful flexibility.  I would be very
disappointed if it didn't give an order of magnitude speed-up, cut the
size of gcc.c at least in half, and make gcc.c more comprehensible.

I'm volounteering to do this.  I'm interested in whether others agree
this is a good and workable plan, things I've missed, difficulties I
might encounter, any reasons why this wasn't done originally, etc.
Particularly when it comes to working across the differing targets.

I realise this would cause a big shakeup of files under the config/
directory at the same time, and is not a GCC 3.0 thing.

Thanks!

Neil.

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

[Joseph S. Myers]

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

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

[Neil Booth]

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.

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

[Joseph S. Myers]

On Sun, 7 Jan 2001, Neil Booth wrote:

> > 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 :-)

The right way to handle this sort of thing is probably for the front end
to pass the definition of __CHAR_UNSIGNED__, or not, to cpplib, after
parsing its options but before preprocessing begins, depending on the
value of flag_signed_char, rather than using specs.  However, this causes
problems when the cpp0 executable gets used - it would probably require
cc1 to handle -E / -save-temps (i.e., producing preprocessor output in
text form) itself.

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

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

[Laurent Guerby]

I'm not a specialist of these GCC flag handling issues, but I think if
this stuff is to be rewritten, it would be neat to think of
documentation issues as well. A way to automatically generate flag
documentation (or describing them with reasonably readable
configuration language) would ensure minimal consitency between
documentation and implementation for the given flag perimiter.

-- 
Laurent Guerby <guerby@acm.org>

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

[Per Bothner]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> Would this also include a cleanup of the argument parsing in toplev.c and
> lang_decode_option?

Can we separate out the table of options from gcc.c and place it
in a separate file so toplev.c etc could use it?  This file might also
include some of the utility routines, like the function that does a
binary search on an option name.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

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

[Neil Booth]

Laurent Guerby wrote:-

> I'm not a specialist of these GCC flag handling issues, but I think if
> this stuff is to be rewritten, it would be neat to think of
> documentation issues as well. A way to automatically generate flag
> documentation (or describing them with reasonably readable
> configuration language) would ensure minimal consitency between
				^^^^^^^^^^^^^^^^^^^^^^^^^
> documentation and implementation for the given flag perimiter.

We have that already with no extra help :-)

Neil.

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

[Neil Booth]

Per Bothner wrote:-

> Can we separate out the table of options from gcc.c and place it
> in a separate file so toplev.c etc could use it?  This file might also
> include some of the utility routines, like the function that does a
> binary search on an option name.

How would you propose handling the fact that the full table would have
combined cpp / C / linker / assembler options (plus C++ / fortran
etc. specific ones)?  It would probably also need some target-specific
options; I've not got much experience in that area.

Maybe we have one master .tab file, for consistency across everything,
and process it through different scripts at GCC compile time depending
upon the user?  gcc.c would want a script that combines everything and
sorts it; other scripts could filter it for whatever toplev.c or
c-decl.c or cp/decl2.c etc. require?

Neil.

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

[Per Bothner]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> Per Bothner wrote:-
> 
> > Can we separate out the table of options from gcc.c and place it
> > in a separate file so toplev.c etc could use it?  This file might also
> > include some of the utility routines, like the function that does a
> > binary search on an option name.
> 
> How would you propose handling the fact that the full table would have
> combined cpp / C / linker / assembler options (plus C++ / fortran
> etc. specific ones)? 

We need the full table for gcc.c.  I don't see how having the same full
table also available for use by toplev.c (and fornt-end options parsing)
changes that.

The table of options should probably be constructed at configure or
make time from lang-specific pieces, and sorted at make time.

> It would probably also need some target-specific
> options; I've not got much experience in that area.

Likewise.  In other words:  I don't really know how this is handled now,
in gcc.c, but some equivalent mechanism can be designed, and if so
why can't the lang front-ends use the same mechanism?

One possible concern:  If gcc reads options from an external file,
we could have the front-ends do the same - but at the cost of an
extra file open.

(Now that we've integrated cpp and the front-ends, the next step
is to integrate the assembler.  After than, we just merge it all
into gcc proper!)

> Maybe we have one master .tab file, for consistency across everything,
> and process it through different scripts at GCC compile time depending
> upon the user?  gcc.c would want a script that combines everything and
> sorts it; other scripts could filter it for whatever toplev.c or
> c-decl.c or cp/decl2.c etc. require?

For example.   Or the front-ends can just use the whole table.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

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

[Neil Booth]

Per Bothner wrote:-

> Likewise.  In other words:  I don't really know how this is handled now,
> in gcc.c, but some equivalent mechanism can be designed, and if so
> why can't the lang front-ends use the same mechanism?

You're right - I was just thinking of reducing the table size for
them, and how to distinguish the relevant options from those that
aren't relevant.  Of course, I had answered the latter point in my
original post - we should use flags - sorry for my confusion.

Target-specific stuff is currently handled in gcc.c by a whole hairy
series of macros and suchlike, I think.  Target-specific HAVE_XYZ
macros, and macros to add target-specific specs, etc.

Neil.

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

[Geoff Keating]

It would be very very nice if, in the new design, data could be shared
between the driver and the machine description so that the following
sort of thing could go away:

"%{mlittle: %(cpp_endian_little) } \
%{mlittle-endian: %(cpp_endian_little) } \
%{mbig: %(cpp_endian_big) } \
%{mbig-endian: %(cpp_endian_big) } \
%{!mlittle: %{!mlittle-endian: %{!mbig: %{!mbig-endian: \
    %{mcall-solaris: %(cpp_endian_solaris) } \
    %{mcall-linux: %(cpp_endian_big) } \
    %{mcall-aixdesc:  %(cpp_endian_big) } \
    %{!mcall-solaris: %{!mcall-linux: %{!mcall-aixdesc: %(cpp_endian_default) }}}}}}}"

All this information is duplicated between this and the actual setting
of endianness in the compiler, and they don't always match properly.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

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

[Michael Meissner]

On Sun, Jan 07, 2001 at 01:14:42PM +0000, Neil Booth wrote:
> Over the last 3 months, changes to cpplib have required updating the
> SPECS handling in gcc.c.  For example, to fix the meaning of '|', and
> to preserve order of -D and -U on the command line.  I think yet
> another spec may be required, similar to what Nathan posted last week,
> for me to handle -MD and -MMD correctly - path preservation but suffix
> replacement.
> 
> A few mails last November with Chris Demetriou inspired me to think of
> better way of doing things.  It strikes me that most patches to gcc.c
> are simply kludges on top of an already gross kludge, and that the
> spec-parsing part of gcc.c is hard to follow.  However, I don't know
> the historical reasons for specs being the way they are, so I may be
> missing something.

I hate to be a kill joy, but specs are quite heavily used, especially by
embedded programers, and I would oppose removing them without providing an
adequate substitute that does not involve rebuilding the gcc driver (cleaning
them up, fixing them, etc. is certainly no problem, though I would argue that
any changes need to be upwards compatible).

The main use of specs in this case, is to override the default libraries,
crt0s, etc. for an environment that is similar to but not the same as the
default GCC environment.  For example, consider a GCC compiler targeting say
the PowerPC (or ARM, x86, etc.).  There are a number of different target boards
(and ultimately each unique embedded device) made by different vendors.  On
long development cycles, a target board may be created and then obsoleted
between GCC releases.  With specs, either the board company or a third party
like Red Hat, can provide a replacement environment for each new board by just
providing a specs file without modifying the base compiler.

Here is the specs file used for one of the PowerPC MBX boards:

	%rename lib                 old_lib
	%rename cpp                 old_cpp
	%rename link                old_link

	*lib:
	--start-group -lmbxbsp -lc -lgcc --end-group %(old_lib)

	*cpp:
	-D__MISSING_SYSCALL_NAMES__ -D__CPU_MPC8XX__ -D__BOARD_MBX__ %(old_cpp)

	*startfile_default:
	ecrti%O%s mbx-crt0%O%s

	*endfile_default:
	ecrtn%O%s

	*link:
	-T bsp.ld%s -Ttext 0x10000 %(old_link)

A second use of specs is to use a common driver file to invoke older compiler
tool chains (ie, with -V).  If the processing is built in, then this will not
be viable.

A third use of specs is to override default options on a local basis, but
editing the specs file.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

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

[Richard Henderson]

On Sun, Jan 07, 2001 at 05:38:00PM -0500, Michael Meissner wrote:
> I hate to be a kill joy, but specs are quite heavily used, especially by
> embedded programers ...

They never should have been though, IMO.

> The main use of specs in this case, is to override the default libraries,
[...]
> A third use of specs is to override default options on a local basis

Both of which can be easily achieved by using a script to 
invoke the gcc driver instead.

I'm in favour of a non-backwards-compatible re-design, if
it actually turns out be clean and maintainable.


r~

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

[Phil Edwards]

On Sun, Jan 07, 2001 at 01:02:14PM -0800, Per Bothner wrote:
> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> 
> > Would this also include a cleanup of the argument parsing in toplev.c and
> > lang_decode_option?
> 
> Can we separate out the table of options from gcc.c and place it
> in a separate file so toplev.c etc could use it?  This file might also
> include some of the utility routines, like the function that does a
> binary search on an option name.

Wow.  I thought I was the only one who had strange ideas for options
handling.  I should have spoken up before.  :-)

In the course of writing up a patch for -print-flags, and trying to make
the lang-specific flags available for printing, I discovered too much
duplication of code amongst the front ends.  I started drawing up a more
generic method involving hashing, and I think it would have made the code
smaller and much faster, but would have involved non-trivial rewrites in
all the front ends.  So I left it and moved on to things I /could/ improve.

Redoing the options handling would be an itch I'd love to help scratch.
(In general, changing the top-level front-end files like gcc.c and toplev.c,
to make adding new front-ends easier, is something I'd be quite interested
in but wouldn't be able to do alone.)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

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

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

    Richard> I'm in favour of a non-backwards-compatible re-design, if
    Richard> it actually turns out be clean and maintainable.

Me too, FWIW.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

main() in toplev.c

[Fergus Henderson]

On 07-Jan-2001, Phil Edwards <pedwards@disaster.jaj.com> wrote:
> (In general, changing the top-level front-end files like gcc.c and toplev.c,
> to make adding new front-ends easier, is something I'd be quite interested
> in but wouldn't be able to do alone.)

One issue with the Mercury front-end is that both GCC (toplev.c)
and the existing Mercury compiler want to be in control at the top
level -- to define main(), to handle argument passing, and so forth.

It would be a lot easier if toplev.c didn't define main(), but instead
defined say toplev_main(), and main() was instead defined in a new file,
called say main.c, to just call toplev_main().  Then I could build the gcc
back-end as a library.  This would make it a lot easier to integrate
this back-end into the rest of the Mercury implementation's infrastructure.

Would such a change be acceptable?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: main() in toplev.c

[Phil Edwards]

On Mon, Jan 08, 2001 at 12:55:00PM +1100, Fergus Henderson wrote:
> 
> Then I could build the gcc
> back-end as a library.

Well, large parts are already scrunched together as an .a file for
convenience.  I believe toplev.c is already included in that collection.
Redefining main() shouldn't be too hard on a language-by-language basis.

(For a moment I thought you meant a shared library.  We don't want to go
there again, not in this thread, not just before a Monday... :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: main() in toplev.c

[Fergus Henderson]

On 07-Jan-2001, Phil Edwards <pedwards@disaster.jaj.com> wrote:
> On Mon, Jan 08, 2001 at 12:55:00PM +1100, Fergus Henderson wrote:
> > 
> > Then I could build the gcc
> > back-end as a library.
> 
> Well, large parts are already scrunched together as an .a file for
> convenience.  I believe toplev.c is already included in that collection.

Sure, I use libbackend.a already.  The point is that I want a version
of it that doesn't define main().

> Redefining main() shouldn't be too hard on a language-by-language basis.

I could put

	#define main toplev_main

in mercury/lang-options.h, I suppose.  Or perhaps in a new file
mercury/lang-main.h.  But I think it would be cleaner to avoid `#define main',
by doing it the way I described in my previous mail, with toplev.c defining
toplev_main() and with main() defined in a different file.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

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

[Zack Weinberg]

I wrote up a similar proposal some time ago.  It had the same plan -
rewrite gcc.c - but a completely different goal.  I wanted to make the
specs language powerful enough to express everything that's now done
with hardwired paths and language specific driver hooks, and make it
easier to read/write at the same time.  The idea was you'd have just
one driver executable, and all the user visible front ends (gcc, g++,
cpp, ...) would be scripts that used it.  This would also make -V and
-b work reliably (between versions with the new driver).

I still think this is a worthy goal, but wouldn't be opposed to going
all out for table driven custom C, either, as long as it's easier to
work with.

You might be able to get a decent speedup out of the existing code by
sorting all the options into pigeonholes by their initial letter.
Then the spec scanners could just look in the appropriate pigeonhole.
Things like %{D*} would have zero additional work to do.  This might
be just as much work as a complete rewrite, though.

Whatever happens, I'd suggest implementing the guts as a dynamic
object that Make etc. could use directly.  I don't have a clear idea
how this should work, but if you get it right you could cut out all
the process creation overhead for invoking the driver on every
compile.

My old proposal is at http://gcc.gnu.org/ml/gcc/1999-03n/msg00754.html .

zw

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

[Davy Durham]

Let me take your argument one step further....

    The following is something I've been looking around for for a while... I've
not seen anything quite powerful enough though... Perhaps this message will
cause someone to remember something they saw some time....
    What I would propose is to start a new project (perhaps a subproject in gcc
or a totally separate one) that is a very powerful comand line parser....
I would suppose that valid argument lists would be described in a text file...
Perhaps this project would be an application that would turn the text file into
a .c file to parse the arguments (like flex or bison).... Or perhaps it would
interpret the text file at runtime.... (should probably work like the first
one)...
The text file would need to describe:
    -whether the flag is a 'there' or 'not there flag' (i.e. -g     in gcc)
    -whether the flag is to be followed 1 or more addition values (i.e. -o
output_filename  in gcc)
    -what to do when a flag encountered (probably similar to the action in
bison)
    -argument dependancies

   With my experience with writing parsers, error handling is much a guess... So
when an invalid argument list is given the text file's language would need to be
written in such a way that errors are not necessarily guesses...

This wouldn't be a simple little project... I don't know what time constraints
we are under here to get the current version working (if it's not)....

What I'm really trying to say is: perhaps focus your efforts on something more
powerful and more general that just rewritting something for gcc.c

Just my thoughts,
    -- Davy

Neil Booth wrote:

> Over the last 3 months, changes to cpplib have required updating the
> SPECS handling in gcc.c.  For example, to fix the meaning of '|', and
> to preserve order of -D and -U on the command line.  I think yet
> another spec may be required, similar to what Nathan posted last week,
> for me to handle -MD and -MMD correctly - path preservation but suffix
> replacement.
>
> A few mails last November with Chris Demetriou inspired me to think of
> better way of doing things.  It strikes me that most patches to gcc.c
> are simply kludges on top of an already gross kludge, and that the
> spec-parsing part of gcc.c is hard to follow.  However, I don't know
> the historical reasons for specs being the way they are, so I may be
> missing something.
>
> Other reasons to replace specs:-
>
> a) They are grossly inefficient.  For example, the common SPEC for CPP
> contains 50 sub-specs now.  Each of these sub-specs requires a
> complete scan of every command-line option.  This amounts to an
> enormous amount of strcmps, when you have an average of 15 to 20
> command line options.  And that's just the common spec for CPP - it
> doesn't include the additional target-specific CPP specs, or the specs
> of the other "compilers", or that every command line option goes
> through another 20 or so strcmps for gcc.c special things like
> "-print-file-name", "-ftarget-help", and maybe yet more for option
> remapping etc.
>
> b) They are inflexible - most processing needs to be expressed in
> terms of specs formulae, or kludged some other way.  I'm thinking of
> things like pipe handling, preserving -U and -D ordering, "GNU C does
> not support -C without using -E" error messages etc. here.  Another
> good example here is that cpplib accepts a whole host of options that
> tradcpp doesn't, e.g. -ftabstop=, but we have no way of telling "gcc"
> to pass them on to cpplib but not to tradcpp that isn't ridiculously
> convoluted.  If you need one more, we pass the -W options on to CPP as
> {W*}.  In order for this to work, CPP has to be coded to silently
> accept -W options that it doesn't understand.  It would be nice if CPP
> could give an error instead.
>
> c) Chris said they make target or processor-specific configuration in
> the config/* files awkward in some cases.  I'm no expert, so I'll take
> his word for that :-)
>
> I would like to suggest a different approach, along the following
> rough lines:
>
> 1) gcc.c contains a sorted table of all command-line options that compilers
>    it drives understands.  This might need to be provided by a separate
>    ".tab" file generated at compile time and #included into gcc.c, for
>    reasons of flexibility over front-ends.
>
> 2) each switch in the table is flagged for such things as which front-ends
>    understand it, whether it takes an appended argument, a separate
>    argument, or both, etc.
>
> 3) for each command line switch, gcc.c uses this information to do a binary
>    search in the table for that switch.  It extracts any argument as
>    appropriate.  [code to do this with slightly less generality
>    already exists in cppinit.c]
>
> 4) Each possible switch has a usage count.  During stage 3, this is
>    incremented as the command line is scanned.  Also, each command-line
>    argument is flagged with which front-ends understand it, and whether
>    it is a switch or argument, etc.
>
> 5) gcc.c works out which compiler chain is needed to perform the compilation,
>    much as it does now from file extensions.  Virtualization through
>    hooks might be needed here.
>
> 6) With 4) and 5), any redundant or unused switches are easily scanned
>    for in a single pass and complained about.
>
> 7) Each compiler has a hook, and it is passed the flagged command-line
>    argument list from 4).  This, and the usage counts in 4), makes it
>    easy to do cleanly extra processing of the kind currently handled
>    by specs like
>
>    %{ffast-math:-D__FAST_MATH__}
>    %{MMD:-MM -MF %b.d}
>
>    At the same time, the compiler-specific hook extracts all the
>    switches flagged for use by its compiler, builds the relevant
>    command line, and invokes its compiler.
>
> I believe the above scheme (where a few details are omitted),
> encapsulates the full functionality provided by specs at present, and
> with the hooks provides more useful flexibility.  I would be very
> disappointed if it didn't give an order of magnitude speed-up, cut the
> size of gcc.c at least in half, and make gcc.c more comprehensible.
>
> I'm volounteering to do this.  I'm interested in whether others agree
> this is a good and workable plan, things I've missed, difficulties I
> might encounter, any reasons why this wasn't done originally, etc.
> Particularly when it comes to working across the differing targets.
>
> I realise this would cause a big shakeup of files under the config/
> directory at the same time, and is not a GCC 3.0 thing.
>
> Thanks!
>
> Neil.

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

[Bruce Korb]

Davy Durham wrote:
> 
> Let me take your argument one step further....
> 
>     The following is something I've been looking around for for a while... I've
> not seen anything quite powerful enough though... Perhaps this message will
> cause someone to remember something they saw some time....
>     What I would propose is to start a new project (perhaps a subproject in gcc
> or a totally separate one) that is a very powerful comand line parser....

  http://AutoGen.SourceForge.net/autoopts

It would require some enhancements, but a *lot* of the stuff
is already in place....

> What I'm really trying to say is: perhaps focus your efforts on something more
> powerful and more general that just rewritting something for gcc.c

There are others out there, but mine is the only one that
approaches having enough feature-itis to be able to cope
with the complex requirements of the GCC suite.  Even still,
there would be some assembly required... :-}

 - Bruce