[Fwd: Re: Merge cc1, cc1plus, etc?]

["Lucas (a.k.a T-Bird or bsdfan3)" <tbird-contact at cox dot net>]

--- Begin Message ---

• From: "Lucas (a.k.a T-Bird or bsdfan3)" <tbird-contact at cox dot net>
• To: gcc-digest-help at gcc dot gnu dot org, sam124 at operamail dot com
• Date: Wed, 22 Dec 2004 12:45:33 -0600
• Subject: Re: Merge cc1, cc1plus, etc?
• References: <1103739910.12620.ezmlm@gcc.gnu.org>

Sounds good, Sam. I was also thinking of putting the machine-specific backend code into shared libraries so that backends could be changed at runtime. This would require backend-related tweaks in configuration, such as allowing the backend to override the normal linker/assembler search path OR (this would require coordination with the binutils folks and would only work with the binutils installed) encoding the Autoconf target into the binutils binaries.

gcc-digest-help@gcc.gnu.org wrote:

ccording 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




--- End Message ---