This is the mail archive of the
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for altivec)
- From: Bernd Schmidt <bernds at redhat dot com>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: Stan Shebs <shebs at apple dot com>, Ira Ruben <ira at apple dot com>, <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Nov 2001 22:40:49 +0000 (GMT)
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
On Tue, 27 Nov 2001, Ziemowit Laski wrote:
> On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote:
> > Well, imagine we try to support not one, but fourty-two poorly designed
> > extensions this way (and it would happen - everyone would go "hey, you
> > did it for Altivec, why can't I put in my feature too"). Imagine trying
> > to make any changes to the C parser if you have to make sure none of
> > these
> > patches break.
> No -- YOU DON'T have to make sure these patches don't break. THAT is the
> responsibility solely of the authors/users of the patch in question.
It sounded like you suggested the patch would be applied automatically
during the build. In that case, the patch would have to be uptodate to
prevent a build failure.
If it isn't applied automatically and requires user intervention, you
could just as well distribute it separately from gcc.
> And yes, I would absolutely allow forty-two poorly designed extensions
> to cohabit with the mainline compiler in this way. :)
If you don't make it the C frontend maintainer's responsibility to keep
them working, you'll end up with fourty-two non-working extensions pretty