Re: Merge cc1, cc1plus, etc?

[Bobby McNulty <bobbymcn at bellsouth dot net>]

Sam Lauber wrote:

> According to the gcc manual page, the semantics of the -B option will change when cc1 and cc1plus are merged. I think it
> would be a good time to do just that. This is my idea of the new semantics (of cc1, too):
>                                                                                                                               
> 1) The executable will be renamed to `gcc1', for `GNU Compiler Collection 1'. I don't know what the 1 on cc1 was for
> (there isn't any cc2, right?), but I kept it.
> 2) The extension-determining code will be merged into the new gcc1 executable. And the -x language code.
> 3) Add an intelligent herustic to gcc1 to determine the language if that fails by asking the parser:
> If the file contains `namespace' or `class' or #include directives without .h or `extern "Language"', it is a C++ file.
> If a pointer to a function in a structure/union is in the file, it is a C file. (Reasoning: C++ and the Objective C
> language have classes and namespaces)
> If the file contains Objective-C language type method of a class, it is (obviously) an Objective C language file.
> If the file contains `use' methods or `String *' types, it is a Java file (But if it contains `typedef char String'
> and `String *' it isn't).
> If the file contains block-structured functions, it is a Fortran file.
> If it contains tree declarations, it is a Treelang file.
> If the file is valid according to nm, it is a linker file.
> Otherwise, if no extensions or -x options are specified, complain and bail out.
> 4) Overturn the C parser the same way the C++ parser was, replacing it with a hand-cranked version. In fact, do that
> with every language.
> 5) Merge these parsers, the extension code, the -x code, and the language herustic code. The advantage of keeping the
> herustic code together is that it can easily ask the new combination parser. A combination parser would also make
> Objective-C++ language support easy, because they can both share code with the C++ parser. In fact, all of the C family
> would share the same common back end (which I think I'll call `Backend C'). I'd think even most Java statements can't
> resist a full Backend C lexical analysis.
> 6) Merge collect2 in to the gcc1 executable. In fact, I think the control flow can be rearranged by running gcc1,
> leaving it running (vfork?), assemble, and resume gcc1. Or maybe even make gcc1 `exec' as. Then, gcc1 could just be
> renamed to gcc, and lots of GCC's lib directory could be freed up. Then -B wouldn't be needed anymore.
>                                                                                                                               
> I think that's so many changes that could be made that a new CVS branch (cc1-merge-and-add-branch?) should be made, if the
> abovementioned are feasible. The end result of that would probably be a cc1 that's value is much more than the sum of its
> parts.
>                                                                                                                               
> Samuel Lauber
>
>  
Sounds good, Sam.
Hope Mark approves this.
Bobby