RE: Re: Proposal/question for GPC

--===============7699789431303339999==
Content-Type: multipart/alternative;
 boundary="=_5f895fcb8abfb5bcf7f1b4b837cfb80e"

--=_5f895fcb8abfb5bcf7f1b4b837cfb80e
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=utf-8

Thanks for the answers!
=20
Scott Franco
=20
--------- Original Message --------- Subject: Re: Proposal/question for GPC
From: "Waldek Hebisch" <[email protected]>
Date: 11/3/20 10:32 am
To: "[email protected]" <[email protected]>

On Mon, Nov 02, 2020 at 01:32:52PM -0700, scott andrew franco wrote:
 > For the GPC authors
 >=20
 > So this could be considered either a proposal or a question, your choice=
=2E
 >=20
 > Recently, for various reasons I have been studying the LLVM project (mai=
nly because I am
 > now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is =
becoming
 > popular as a backend. For example, I believe FPC now uses it.
 >=20
 > An interesting thing about LLVM is that they bent over backwards to make=
 sure it was as
 > compatible as possible with previous GCC methods, components and front-e=
nds, with
 > an eye to making it easy to port existing front ends to LLVM.
=20
 Actually, LLVM started as alternative optimizer for gcc. IIUC it
 never had all features needed for various gcc frontends. Currently
 compatibility features with gcc frontends seem to be phased out
 (or gone). IIUC Jonas wrote the same...
 >
 > So I think you can guess where I am going with this. The GPC group dropp=
ed the GPC
 > project mainly because GCC had changed and the requirements to meet the =
new
 > GCC backend were too large to meet for the GPC group (WRT: Quo vas GPC)=
=2E
=20
 That is simplified point of view. At least for me it was a set of
 reasons. More accurate statement would be that I decided to
 pursue another projects instead of adapting GPC to new backends.
 Put it differently: for me gain/effort ratio was too small.
 And let me remark that old backends work for me (with
 rather crude patch for contemporary Debian).
=20
 > Might that have changed with the introduction of LLVM? It would seem tha=
t the GPC front
 > end would be a perfect match for LLVM, and the problems with upgrading t=
o the current
 > GCC backend may be solved with using LLVM as backend?
=20
 In case I did not mention this earlier: one of my students used
 LLVM as a backend for compiler project. In about 2-3 years
 his compiler was broken by changes to LLVM and he gave up.
=20
 --=20
 Waldek Hebisch
=20
 _______________________________________________
 Gpc mailing list
 [email protected]
 https://www.g-n-u.de/mailman/listinfo/gpc

--=_5f895fcb8abfb5bcf7f1b4b837cfb80e
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
 charset=utf-8

<div>Thanks for the answers!</div>
<div>&nbsp;</div>
<div>Scott Franco</div>
<div>&nbsp;</div>
<blockquote class=3D"threadBlockQuote" style=3D"border-left: 2px solid #C2C=
2C2; padding-left: 3px; margin-left: 4px;">--------- Original Message -----=
----
<div>Subject: Re: Proposal/question for GPC<br />From: "Waldek Hebisch" &lt=
;[email protected]&gt;<br />Date: 11/3/20 10:32 am<br />To: "gpc@gnu=
=2Ede" &lt;[email protected]&gt;<br /><br />On Mon, Nov 02, 2020 at 01:32:52PM -07=
00, scott andrew franco wrote:<br /> &gt; For the GPC authors<br /> &gt; <b=
r /> &gt; So this could be considered either a proposal or a question, your=
 choice.<br /> &gt; <br /> &gt; Recently, for various reasons I have been s=
tudying the LLVM project (mainly because I am<br /> &gt; now forced to use =
LLVM on the Mac OS X). As I am sure you know, LLVM is becoming<br /> &gt; p=
opular as a backend. For example, I believe FPC now uses it.<br /> &gt; <br=
 /> &gt; An interesting thing about LLVM is that they bent over backwards t=
o make sure it was as<br /> &gt; compatible as possible with previous GCC m=
ethods, components and front-ends, with<br /> &gt; an eye to making it easy=
 to port existing front ends to LLVM.<br /> <br /> Actually, LLVM started a=
s alternative optimizer for gcc. IIUC it<br /> never had all features neede=
d for various gcc frontends. Currently<br /> compatibility features with gc=
c frontends seem to be phased out<br /> (or gone). IIUC Jonas wrote the sam=
e...<br /> &gt;<br /> &gt; So I think you can guess where I am going with t=
his. The GPC group dropped the GPC<br /> &gt; project mainly because GCC ha=
d changed and the requirements to meet the new<br /> &gt; GCC backend were =
too large to meet for the GPC group (WRT: Quo vas GPC).<br /> <br /> That i=
s simplified point of view. At least for me it was a set of<br /> reasons=
=2E More accurate statement would be that I decided to<br /> pursue another=
 projects instead of adapting GPC to new backends.<br /> Put it differently=
: for me gain/effort ratio was too small.<br /> And let me remark that old =
backends work for me (with<br /> rather crude patch for contemporary Debian=
).<br /> <br /> &gt; Might that have changed with the introduction of LLVM?=
 It would seem that the GPC front<br /> &gt; end would be a perfect match f=
or LLVM, and the problems with upgrading to the current<br /> &gt; GCC back=
end may be solved with using LLVM as backend?<br /> <br /> In case I did no=
t mention this earlier: one of my students used<br /> LLVM as a backend for=
 compiler project. In about 2-3 years<br /> his compiler was broken by chan=
ges to LLVM and he gave up.<br /> <br /> -- <br /> Waldek Hebisch<br /> <br=
 /> _______________________________________________<br /> Gpc mailing list<=
br /> [email protected]<br /> https://www.g-n-u.de/mailman/listinfo/gpc</div>
</blockquote>

--=_5f895fcb8abfb5bcf7f1b4b837cfb80e--


--===============7699789431303339999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gpc mailing list
[email protected]
https://www.g-n-u.de/mailman/listinfo/gpc

--===============7699789431303339999==--