From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13336 invoked by alias); 28 Nov 2001 15:11:31 -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 13293 invoked from network); 28 Nov 2001 15:11:26 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 15:11:26 -0000 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA06981 for ; Wed, 28 Nov 2001 07:11:24 -0800 (PST) Received: (from aldyh@localhost) by localhost.localdomain (8.11.6/8.11.6) id fASFDko08942; Wed, 28 Nov 2001 09:13:46 -0600 X-Authentication-Warning: localhost.localdomain: aldyh set sender to aldyh@redhat.com using -f To: Mark Mitchell Cc: Stan Shebs , Per Bothner , Ziemowit Laski , Ira Ruben , "gcc@gcc.gnu.org" Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) References: <74650000.1006922092@gandalf.codesourcery.com> From: Aldy Hernandez Date: Tue, 20 Nov 2001 17:03:00 -0000 In-Reply-To: <74650000.1006922092@gandalf.codesourcery.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00977.txt.bz2 >>>>> "Mark" == Mark Mitchell writes: > Let's try a different tack. What are we going to do about: > (vector int)(1, 2, 3, 4) ...not going to be supported on fsf sources. Too ugly. Nobody can intellectually reconcile the above nastiness. I need to implement the above anyhow, but i suppose it will be provided on additional set of, i suppose, apple+redhat supported patches, never to be incorporated into gcc. > Are we going to try to accept this syntax, or require the C99-like: > (vector int){1, 2, 3, 4} yes > 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. See the last response by rth. He came up with a way in which we can just specify the total vector size in an attribute and determine the vector mode from the type being modified (int, in this case). So, we should be able to cater to both parties-- a more generic approach, and a few macros to implement altivec syntax, modulo the () initializers. > 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? Yes, but after all this discussion, everything seems to have fallen into place with the exception of "(1, 2, 3, 4)". So these will have to be provided for in external patches. Aldy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aldy Hernandez To: Mark Mitchell Cc: Stan Shebs , Per Bothner , Ziemowit Laski , Ira Ruben , "gcc@gcc.gnu.org" Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Wed, 28 Nov 2001 07:11:00 -0000 Message-ID: References: <74650000.1006922092@gandalf.codesourcery.com> X-SW-Source: 2001-11/msg01478.html Message-ID: <20011128071100.sqPV4weZl7HoTPmmwyx0AYDBLMulNBPs-B_M1WqVP3A@z> >>>>> "Mark" == Mark Mitchell writes: > Let's try a different tack. What are we going to do about: > (vector int)(1, 2, 3, 4) ...not going to be supported on fsf sources. Too ugly. Nobody can intellectually reconcile the above nastiness. I need to implement the above anyhow, but i suppose it will be provided on additional set of, i suppose, apple+redhat supported patches, never to be incorporated into gcc. > Are we going to try to accept this syntax, or require the C99-like: > (vector int){1, 2, 3, 4} yes > 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. See the last response by rth. He came up with a way in which we can just specify the total vector size in an attribute and determine the vector mode from the type being modified (int, in this case). So, we should be able to cater to both parties-- a more generic approach, and a few macros to implement altivec syntax, modulo the () initializers. > 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? Yes, but after all this discussion, everything seems to have fallen into place with the exception of "(1, 2, 3, 4)". So these will have to be provided for in external patches. Aldy