From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17884 invoked by alias); 27 Jun 2010 21:20:05 -0000 Received: (qmail 17870 invoked by uid 22791); 27 Jun 2010 21:20:04 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,BOTNET,RDNS_NONE X-Spam-Check-By: sourceware.org Received: from Unknown (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Jun 2010 21:20:01 +0000 Received: (qmail 23577 invoked from network); 27 Jun 2010 21:19:59 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Jun 2010 21:19:59 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1OSzGg-0003O6-0l; Sun, 27 Jun 2010 21:19:58 +0000 Date: Sun, 27 Jun 2010 22:31:00 -0000 From: "Joseph S. Myers" To: Joern Rennecke cc: Mark Mitchell , Steven Bosscher , gcc-patches@gcc.gnu.org Subject: Re: RFA: Fix other/44566 In-Reply-To: <20100627164133.mag8uuvehwk8wg0o-nzlynne@webmail.spamcop.net> Message-ID: References: <20100626061802.45a3nzzz4088o840-nzlynne@webmail.spamcop.net> <4C277C28.1060201@codesourcery.com> <4C27810D.9030705@codesourcery.com> <20100627140458.oou4kzesyskwgg8w-nzlynne@webmail.spamcop.net> <20100627152431.gq8x5kalcg4gk08g-nzlynne@webmail.spamcop.net> <20100627164133.mag8uuvehwk8wg0o-nzlynne@webmail.spamcop.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg02785.txt.bz2 On Sun, 27 Jun 2010, Joern Rennecke wrote: > I don't think it is merely a workaround; I think it is a proper > implementation. I think a proper implementation has the totality of the definition of the interface for targets to define in just one place, i.e. the definition of the target structure and its associated documentation. Targets providing headers that target-independent code includes involves a hole in this interface definition that makes it hard to tell quite what the interface is (enumerating target macros is hard when any identifier could be a macro). Clarity and clear definition of internal interfaces is good in itself, and avoiding macros where possible generally helps make interfaces clearer and easier to analyze. Certainly I'd consider that the function-like target macros, and others that expand to code rather than constants, are the highest priority to convert to hooks (and also less likely to have much performance impact; the targets with more complicated expansions hopefully already use function calls in the definitions of their macros). This does not prevent tricks to build a file multiple times if that is really felt to be necessary (you could build it with your namespaces and with targetm defined to be a const target vector for a particular target, so that LTO/WHOPR can separately optimize the functions for each target). -- Joseph S. Myers joseph@codesourcery.com