From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14299 invoked by alias); 26 May 2011 12:18:59 -0000 Received: (qmail 14286 invoked by uid 22791); 26 May 2011 12:18:59 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_XG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 May 2011 12:18:42 +0000 Received: (qmail 26992 invoked from network); 26 May 2011 12:18:41 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 May 2011 12:18:41 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QPZWS-0008BZ-BW; Thu, 26 May 2011 12:18:40 +0000 Date: Thu, 26 May 2011 13:24:00 -0000 From: "Joseph S. Myers" To: Rainer Orth cc: Richard Henderson , Anatoly Sokolov , gcc-patches@gcc.gnu.org, ebotcazou@libertysurf.fr Subject: Re: Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P) In-Reply-To: Message-ID: References: <9410569723.20110427221316@post.ru> <4DB98D4D.2050107@redhat.com> 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: 2011-05/txt/msg02020.txt.bz2 On Thu, 26 May 2011, Rainer Orth wrote: > But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to > libgcc/config for all targets together? How can you poison the macro > when a single target using it is left behind in gcc/config? Nothing about the libgcc_tm.h implementation stops you moving a macro (that is not, in fact, used on the host) for only some targets if you don't poison it. But I do think moving it for all targets together, and poisoning it, is much better. > To actually test such a move, one had to setup complete > cross-environments for every affected target, which is way beyond what I > have the time and inclination to do. This would mean that even targets > where the toplevel libgcc move could be completed and the maintainers > are motivated to do so are stalled until all other related ones are > done. Doesn't seem highly desirable to me. Well, no, you post the patch (I'd guess all thirty or so target-only macros could be moved in a few hours, but moving them in smaller groups might be easier), test on the targets you can readily test on (building just cc1 and xgcc for the others), invite target maintainers (CC:ed) to test for other targets and seek approval to commit in maybe a week in the absence of problem reports from target maintainers. I think completing the move for a particular macro is more meaningful, and has a better way to ensure the move doesn't regress, than completing it for a particular target. -- Joseph S. Myers joseph@codesourcery.com