From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: Joe Buck Cc: Ziemowit Laski , "Joseph S. Myers" , "gcc@gcc.gnu.org" Subject: Re: Target-specific Front-Ends? (Was: front end changes for Date: Tue, 27 Nov 2001 15:32:00 -0000 Message-ID: <32170000.1006903600@gandalf.codesourcery.com> References: <200111272253.OAA01671@atrus.synopsys.com> X-SW-Source: 2001-11/msg01416.html Message-ID: <20011127153200.oAQtKFG46htSAOtlulhjZBN6aSfgFni807EK_uxVuFk@z> --On Tuesday, November 27, 2001 02:53:26 PM -0800 Joe Buck wrote: > Mark writes: >> Concretely, the Altivec specification allows "vector" to be either a >> macro, or a context-sensitive keyword. The latter is a much better >> choice, and it is the one we should adopt in GCC. It will be far >> less intrusive. > > Allowing "vector" to be a macro would be completely unacceptable, because > people will mix C and C++ code. The Altivec specification says that __vector is a keyword. It says that vector can be either a macro or a context-sensitive keyword. If it is a macro you are explicitly allowed to #undef it. So, you can use __vector in C or C++, with any Altivec compiler. If you're using (Altivec) vector in C++ code, you're not writing portable code, even across Altivec implementations. I don't know how many Altivec code authors know this, but we would certainly be within the letter of the law going this way, and it's (relatively) easy to implement, and far less horrid than a context-sensitive keyword. >> Other things are more difficult. Vector literals should just be >> C99 compound literals, but I'm not sure whether we can get away >> with changing that or not. > > A modest proposal: > > Consider a preprocessor that takes current Altivec C code and produces > either standard or extended C code (GNU extensions). If adopting the > existing Altivec syntax is too painful, a second choice might be to figure > out syntax choices that would make such a preprocessor very easy to write. > Then we don't have to ask existing users to rewrite their code. Yup, I thought about this too. It's plausible, but a pretty substantial effort, and not easy to do robustly with the tools we've got. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com