From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14451 invoked by alias); 4 Dec 2001 08:14:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14413 invoked from network); 4 Dec 2001 08:14:54 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 4 Dec 2001 08:14:54 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id fB48ErX12421 for ; Tue, 4 Dec 2001 00:14:53 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 4 Dec 2001 00:14:22 -0800 Received: from [17.201.22.70] (roseal.apple.com [17.201.22.70]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id fB48EbD19817; Tue, 4 Dec 2001 00:14:37 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 04 Dec 2001 00:14:00 -0000 Subject: Re: Target-specific Front-Ends? (Was: front end changes for From: Alex Rosenberg To: Mark Mitchell CC: Ziemowit Laski , "Joseph S. Myers" , Aldy Hernandez , Joe Buck , egcs Message-ID: In-Reply-To: <32170000.1006903600@gandalf.codesourcery.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2001-12/txt/msg00107.txt.bz2 (Sorry for the late response...) on 11/27/01 3:26 PM, Mark Mitchell at mark@codesourcery.com wrote: > --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. I just wanted to point out that the AltiVec PIM "specification" contains this macro allowance (2.2.1) as a concession to the former Metrowerks engineer who was responsible for AltiVec support. The same is true of the entire discussion of the optional include file in 2.6. At that time, he didn't understand Ira's explanations of "context-sensitive keyword" (much as many on the gcc list seem to not understand it). 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? +------------------------------------------------------------+ | Alexander M. Rosenberg | | Nobody cares what I say. Remove the underscore to mail me. |