From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25912 invoked by alias); 10 Jun 2004 19:54:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25898 invoked from network); 10 Jun 2004 19:54:53 -0000 Received: from unknown (HELO lon-mail-4.gradwell.net) (193.111.201.130) by sourceware.org with SMTP; 10 Jun 2004 19:54:53 -0000 Received: (qmail 71918 invoked from network); 10 Jun 2004 19:54:52 -0000 Received: from digraph.polyomino.org.uk (postmaster%pop3.polyomino.org.uk@81.187.227.50) by lon-mail-4.gradwell.net with SMTP; 10 Jun 2004 19:54:52 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.34) id 1BYVdU-0002Ih-2z; Thu, 10 Jun 2004 19:54:52 +0000 Date: Thu, 10 Jun 2004 21:25:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Zack Weinberg cc: Phil Edwards , law@redhat.com, Jerry Quinn , gcc-patches@gcc.gnu.org Subject: Re: [patch] Minor improvement to typeclass.h In-Reply-To: <87r7snb5ss.fsf@taltos.codesourcery.com> Message-ID: References: <877julhhlb.fsf@codesourcery.com> <1086817343.18174.320.camel@speedy> <878yevcm11.fsf@taltos.codesourcery.com> <20040610183105.GA22168@disaster.jaj.com> <87r7snb5ss.fsf@taltos.codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-06/txt/msg00676.txt.bz2 On Thu, 10 Jun 2004, Zack Weinberg wrote: > Ah. tgmath.h. Yeah, that's good enough reason to keep the extension, > although here's a place where a dialogue with glibc people could > probably result in a better implementation. (Same sort of icky macros > you find in altivec.h.) Though I helped with the design of the built-ins used to implement altivec.h, having seen the resulting altivec.h and the problems associated with it I don't think it's proved to be a good direction to go in. (Part of the blame must be laid at the designers of an Altivec specification that didn't give its extensions as amendments to ISO C fitting cleanly within the text and spirit of the document.) I'd still prefer the sort of overloaded built-ins described in projects/index.html to implement (in particular, to avoid the explosion of nested macro text expansions, each parameter should appear once only in the macro text). OTOH I don't really care for adding new extensions either, though this sort of extension (rather than the mess we have) is clearly envisaged by ISO C. (The __builtin_classify_type uses were in Ulrich's part of 2000-08-01 Ulrich Drepper Joseph S. Myers * math/tgmath.h: Make standard compliant. Don't ask how. ; I had expected Ulrich to have better taste for comprehensibility of code than to consider such obscure code as a serious candidate for inclusion in glibc rather than proof that something *could* be done with GCC as is but you wouldn't want to use the necessary code.) -- Joseph S. Myers jsm@polyomino.org.uk