From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20681 invoked by alias); 26 May 2011 12:31:19 -0000 Received: (qmail 20673 invoked by uid 22791); 26 May 2011 12:31:18 -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 snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 May 2011 12:31:04 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 11C5438A; Thu, 26 May 2011 14:31:03 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MYK3nd85xHcD; Thu, 26 May 2011 14:31:00 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 6015B389; Thu, 26 May 2011 14:31:00 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.4+Sun/8.14.4/Submit) id p4QCUxu8017705; Thu, 26 May 2011 14:30:59 +0200 (MEST) From: Rainer Orth To: "Joseph S. Myers" Cc: Richard Henderson , gcc-patches@gcc.gnu.org Subject: Re: Completing toplevel libgcc move References: <9410569723.20110427221316@post.ru> <4DB98D4D.2050107@redhat.com> Date: Thu, 26 May 2011 13:31:00 -0000 In-Reply-To: (Joseph S. Myers's message of "Thu, 26 May 2011 12:18:40 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg02023.txt.bz2 "Joseph S. Myers" writes: > 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. Ok, I see. It sounded to me as you wanted to somehow discourage/prohibit those partial moves by policy. Clearly achieving some consistency here is a laudable goal and far better than having just another incomplete transition that lingers forever. >> 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. Ok, that sounds doable. AFAICS, the only ones of interest to my targets are MD_UNWIND_SUPPORT and ENABLE_EXECUTE_STACK. I'll probably do those separately once the basic toplevel libgcc moves for Solaris, Tru64 UNIX and IRIX are in. Right now, I'm close for Solaris, but just noticed that sparc/sol2-c[in].asm are used by sparc*-elf and sparc*-rtems, too, so I'll have to deal with them as well before sparc*-*-solaris2* can be done. The other two are pratically done, but rely on the Solaris move to go in first. > 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. On the other hand, doing it per target has the advantage that you can easily test the whole beast once, detect may cleanup opportunities, and be done with it, rather than redoing the stuff on a per-macro basis. But my targets above indicate that the number of macros per target may actually be quite small. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University