This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Let's kill specs, completely rewrite gcc.c
Neil Booth <email@example.com> 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)
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.