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


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.

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