This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Alex Rosenberg <alexr at spies dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Ziemowit Laski <zlaski at apple dot com>, "Joseph S. Myers" <jsm28 at cam dot ac dot uk>, Joe Buck <jbuck at synopsys dot com>, egcs <gcc at gcc dot gnu dot org>
- Date: 04 Dec 2001 11:28:33 -0800
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for
- References: <B831C5EE.52C5A%alexr@spies.com>
> Shortly before MW shipped their first AltiVec support release, they switched
> over to the context-sensitive "vector" method (2.2.2). Pretty much every
> line of existing AltiVec code uses "vector" in this way.
>
> It seems to me that a major problem with target-dependant front-end
> extensions like this is that the front-ends are automatically built from a
> grammar and installers aren't required to have those tools.
>
> Would the new C++ front-end make this less difficult?
the consensus on a least intrusive method, is to have "__vector" expand
to "__attribute__((vector_size(n))". this way, no changes are needed to
the front end per se. and yes, we will require you to include
<altivec.h>
>
> +------------------------------------------------------------+
> | Alexander M. Rosenberg <mailto:alexr@_spies.com> |
> | Nobody cares what I say. Remove the underscore to mail me. |
>
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.