From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 608 invoked by alias); 4 May 2011 11:50:12 -0000 Received: (qmail 599 invoked by uid 22791); 4 May 2011 11:50:12 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_BJ,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; Wed, 04 May 2011 11:49:56 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id DF8DB21B; Wed, 4 May 2011 13:49:54 +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 PvXoBJYLiDjW; Wed, 4 May 2011 13:49:52 +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 9C55D219; Wed, 4 May 2011 13:49:52 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.4+Sun/8.14.4/Submit) id p44Bnphm007370; Wed, 4 May 2011 13:49:51 +0200 (MEST) From: Rainer Orth To: "Joseph S. Myers" Cc: Richard Henderson , Anatoly Sokolov , gcc-patches@gcc.gnu.org, ebotcazou@libertysurf.fr Subject: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P References: <9410569723.20110427221316@post.ru> <4DB98D4D.2050107@redhat.com> Date: Wed, 04 May 2011 11:54:00 -0000 In-Reply-To: (Joseph S. Myers's message of "Tue, 3 May 2011 19:15:56 +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/msg00281.txt.bz2 "Joseph S. Myers" writes: >> What is so hard about running grep when removing/renaming symbols??? > > Generically, the presence of lots of nonobvious places that may turn out > to use a symbol - ada/gcc-interface/, go/gofrontend, config/ for what one > thinks of as front-end symbols, libgcc/ and other places outside of gcc/ > (being outside gcc/ is probably how the remaining use of ROUND_TYPE_SIZE > in libobjc was missed when that macro was removed from GCC in 2003), C > symbols used directly in Ada source code, .... The ongoing work on > narrowing interfaces (so that it's well-defined whether particular headers > are used for the host or the target, tm.h isn't included in so many > places, etc.) may help - though another thing to watch out for there is > random declarations in .c files or inappropriate headers that mean that > something uses a symbol from some part of the compiler despite not > including the normal header that declares it (I found plenty of such cases > when making options variables into macros). Help in cleaning up > interfaces is always welcome - there's a lot to do > ( has notes dealing > with the very narrow area of target macros in code built for the target). certainly true in general, although grep -r over the whole tree isn't too hard to use either ;-) But in the case at hand, $ grep print_operand * in gcc/config/sparc would have turned up the problem at once, that's why I'm complaining. Your expansion of the wiki page on toplevel libgcc migration is certainly welcome: I hadn't seen before that *-unwind.h files and related macros can be moved over as well. Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University