Merge cc1, cc1plus, etc?

[Bobby McNulty]

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