This is the mail archive of the 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]

GCC Needs a backend cleanup and complete rewrite

Hey guys,

Nice little bombshell for ya. GCC is a bloody mess. Just where is one
supposed to start in building a new front end is a pressing one, since even
the scant documentation available doesn't really shed much light on the
issue. I'm not directing my woes to anyone at all, in fact it shows great
programming skill that the GCC and friends folks can do anything with GCC in
its current state.

Physically, how much longer can GCC go on in its current state without
breaking everywhere? In hindsight, perhaps this is directed at RMS, can the
GCC language used in backend issues be designed a lot more cleanly with a
clearly defined and superbly documented "API" for programmers wanting to add
new languages?

I'm sure it is possible to have a "pseudo assembler" kind of IR and the
abovesaid API which generates it from new languages, and working in
conjunction with the API which provides a higher look at IF-THEN-ELSE and
DO-WHILE etc, say a nice clean interface.

Maybe an object-oriented, Standard C++ implemented GCC release 5 which is a
complete rewrite is called for, with teams of volunteers coordinated by RMS
for design, specs, coding, documentation, testing, debugging, API design,

I'm certainly not afraid to take such a leap. A beautiful and
("relatively?") easy to use method of implementing a new language front end
is a dream come true for idiots like me who can't grasp where I am supposed
to start anyway, let alone implement my new language.

How about a new front end which just looks something like this:

GCCObject *gcc = new GCC("language");
delete gcc;
return 0;


Well.... what do you think?

James Buchanan

----- Original Message -----
From: "Linus Torvalds" <>
To: <>
Sent: Wednesday, February 21, 2001 9:03 PM
Subject: Re: Shared library annoyance with gcc-3_0-branch

> In article <>,
> Clive Nicolson  <> wrote:
> >
> >Linux and other OS's (or runtime systems) need either to provide EH
> >support as part of the "system" (VMS does this, as do other well
> >designed systems).
> This is not necessarily a bad idea to strive for.  But in practice it
> tends to be scuttled by the need to support older versions, and support
> OS's that you can't easily change.
> >My feeling is that it would be better if the linux gurus provided a
> >and forward compatible unique name/value system rather than a builtin EH
> You can easily do it in user space with a number of approaches. One is
> to reserved a specific area of virtual memory, and use that as a global
> pointer. The problem is the "backwards compatibility", and the fact that
> glibc people seem to have a hard time communicating.
> Both of these are easy to solve if you just bite the bullet and make
> glibc jump to the next major number together with gcc-3.0 and say that
> gcc exception handling doesn't work with glibc-6, and vice versa.
> But for some reason I've never understood, glibc people don't seem to
> like changing the version number.  In fact, last I looked, HJL created
> an incompatible library and called it the same old version on purpose.
> So this solution doesn't seem to be a valid solution, even if it's easy.
> (Personally, I think that glibc should be _forced_ to change it's
> version number every time it comes up with a new release, and only use
> the minor numbers for the _really_ small changes that do not change any
> behaviour or add any new functionality.  I'd rather have five copies of
> the libraries than have one library that doesn't really work with all
> binaries).
> Basically, I'm saying that the whole "Linux" issue doesn't exist. It's a
> "glibc" issue, and even there it seems to be more about people than
> about technology. Which is so often the case.
>                 Linus

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