From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25718 invoked by alias); 28 Nov 2001 01:37:35 -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 25672 invoked from network); 28 Nov 2001 01:37:32 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 01:37:32 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id fAS1bVu10169 for ; Tue, 27 Nov 2001 17:37:31 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 27 Nov 2001 17:37:30 -0800 Received: from patel (patel.apple.com [17.202.42.200]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id fAS1bTH15624; Tue, 27 Nov 2001 17:37:29 -0800 (PST) Date: Tue, 20 Nov 2001 00:56:00 -0000 Subject: Re: Target-specific Front-Ends? (Was: front end changes for Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: Devang Patel , Joe Buck , Ziemowit Laski , "Joseph S. Myers" , "gcc@gcc.gnu.org" To: Mark Mitchell From: Devang Patel In-Reply-To: <32170000.1006903600@gandalf.codesourcery.com> Message-Id: <02B7BD8A-E3A1-11D5-BBB3-00306558FC20@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) X-SW-Source: 2001-11/txt/msg00942.txt.bz2 On Tuesday, November 27, 2001, at 03:26 PM, Mark Mitchell 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 think, main reason to make vector context-sensitive keyword was -- allow it to coexist with C++ stl vector. If context-sensitive keyword is highly undesirable then bettor solution is to only support __vector and drop vector macro. And force user to adapt __vector keyword. If user complains, we can always point him/her to this thread :-) I would also resist the temptation to support vector macro only for C. Devang From mboxrd@z Thu Jan 1 00:00:00 1970 From: Devang Patel To: Mark Mitchell Cc: Devang Patel , Joe Buck , 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 17:37:00 -0000 Message-ID: <02B7BD8A-E3A1-11D5-BBB3-00306558FC20@apple.com> References: <32170000.1006903600@gandalf.codesourcery.com> X-SW-Source: 2001-11/msg01443.html Message-ID: <20011127173700.EoxTZDSUG-x6mcl-kyD8nOXPDlITVhlkbrJ3N2v8tns@z> On Tuesday, November 27, 2001, at 03:26 PM, Mark Mitchell 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 think, main reason to make vector context-sensitive keyword was -- allow it to coexist with C++ stl vector. If context-sensitive keyword is highly undesirable then bettor solution is to only support __vector and drop vector macro. And force user to adapt __vector keyword. If user complains, we can always point him/her to this thread :-) I would also resist the temptation to support vector macro only for C. Devang