From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7658 invoked by alias); 28 Nov 2001 04:40:21 -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 7629 invoked from network); 28 Nov 2001 04:40:20 -0000 Received: from unknown (HELO gandalf.codesourcery.com) (66.60.148.227) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 04:40:20 -0000 Received: from gandalf.codesourcery.com (IDENT:mitchell@localhost [127.0.0.1]) by gandalf.codesourcery.com (8.11.6/8.11.6) with ESMTP id fAS4Yq800700; Tue, 27 Nov 2001 20:34:52 -0800 Date: Tue, 20 Nov 2001 11:37:00 -0000 From: Mark Mitchell To: Stan Shebs , Per Bothner cc: Ziemowit Laski , Ira Ruben , "gcc@gcc.gnu.org" Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Message-ID: <74650000.1006922092@gandalf.codesourcery.com> In-Reply-To: <3C044730.F10E0152@apple.com> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2001-11/txt/msg00960.txt.bz2 >> Let me answer for you: We don't. > > Who's this "we" you're referring to? > > Zem's proposal does challenge GCC orthodoxy, but in the past > you've been the one to question the rules imposed by other people. Let's be very careful to keep this polite. It's right on the edge at the moment; everyone is getting tense. No SHOUTING, please; and let's not try to shut anyone up either. Let's try a different tack. What are we going to do about: (vector int)(1, 2, 3, 4) Are we going to try to accept this syntax, or require the C99-like: (vector int){1, 2, 3, 4} If the latter, then we have a source-incompatible change. Once we do that, all Altivec users have to change their code, and changing "vector int" into "__attribute__((vector(4)) int" is not a whole lot worse. I think the fundamental question is not what to do about vector; it's whether or not we're going to try to implement the Altivec syntax or just its semantics. It seems that most people would prefer the latter, but that the folks at Apple would prefer the former. Apple would like to stop having to merge the Altivec patches, and they do not seem to believe that users will be willing to change their code. Is that right? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: Stan Shebs , Per Bothner Cc: Ziemowit Laski , Ira Ruben , "gcc@gcc.gnu.org" Subject: Re: Target-specific Front-Ends? (Was: front end changes foraltivec) Date: Tue, 27 Nov 2001 20:40:00 -0000 Message-ID: <74650000.1006922092@gandalf.codesourcery.com> References: <3C044730.F10E0152@apple.com> X-SW-Source: 2001-11/msg01461.html Message-ID: <20011127204000.ivm_BowbF6lnM7Xun8AWsL80mQ0v8AUzhODhP5_RWW8@z> >> Let me answer for you: We don't. > > Who's this "we" you're referring to? > > Zem's proposal does challenge GCC orthodoxy, but in the past > you've been the one to question the rules imposed by other people. Let's be very careful to keep this polite. It's right on the edge at the moment; everyone is getting tense. No SHOUTING, please; and let's not try to shut anyone up either. Let's try a different tack. What are we going to do about: (vector int)(1, 2, 3, 4) Are we going to try to accept this syntax, or require the C99-like: (vector int){1, 2, 3, 4} If the latter, then we have a source-incompatible change. Once we do that, all Altivec users have to change their code, and changing "vector int" into "__attribute__((vector(4)) int" is not a whole lot worse. I think the fundamental question is not what to do about vector; it's whether or not we're going to try to implement the Altivec syntax or just its semantics. It seems that most people would prefer the latter, but that the folks at Apple would prefer the former. Apple would like to stop having to merge the Altivec patches, and they do not seem to believe that users will be willing to change their code. Is that right? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com