contribution 3

[Alexey Starovoytov]

Hi,

Richard, If you want it to run with GCC only it will.
It would be really difficult to get it work with proprietary compiler
after that.

Per, what is your opinion about my contribution?

I remember some time ago you wrote:
-------------------------------------------
Now if your tool was written as a *hack-end* to Gcc, rather than a
stand-alone tool, then it might be different.  That would be much
more useful, as it could allow use of *other languages* (such as
C++ or Ada) on platforms that have a C compiler, but which Gcc has
not been ported to, or on which the Gcc compiler is no longer being
maintained.

I'm not guaranteeing we would accept that (there are still poltical
and competitive concerns), but at least there you would have a much
stronger case for inclusion and support.
-------------------------------------------

My patch Is a hack-end to gcc.

I think it might be useful in porting GNU application to the new
platforms where only C compiler exists.

It's interesting scientific tool.
As Andi Kleen wrote:
"A more important aspect of such a compiler would be idempotency."

Of course it generates "close to ANSI" C code, but it could be modified
to generate pure GNU C with extensions, so no other compiler except
GCC will accept such C sources.

It may be useful to boost some Fortran application, as 172.mgrid showed.

Finally, it generates a lot of C code, so could be used as a part of testsuite.

Best regards,
Alexey.


---------- Forwarded message ----------
Date: Thu, 18 Apr 2002 00:08:25 -0700
From: Richard Henderson <rth@redhat.com>
To: Alexey Starovoytov <stork@sun.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: contribution 3

On Wed, Apr 17, 2002 at 07:07:03PM -0700, Alexey Starovoytov wrote:
> Please tell me what do you think.

I think there's no chance that this will ever be accepted.

The only use for this I can see is to have a proprietary
compiler use the GNU front ends to (1) parse languages that
the proprietary compiler can't handle or (2) parse GNU C
extensions common in free software or (3) avoid developing
a proper GCC machine description for a new processor or
(4) avoid contributing significant optimizations already
present in a vendor compiler.

All of which are goals we neither support nor facilitate.


r~