From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11566 invoked by alias); 3 May 2011 19:16:14 -0000 Received: (qmail 11556 invoked by uid 22791); 3 May 2011 19:16:13 -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 mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 19:15:58 +0000 Received: (qmail 24611 invoked from network); 3 May 2011 19:15:57 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 May 2011 19:15:57 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QHL4e-0003Dt-Do; Tue, 03 May 2011 19:15:56 +0000 Date: Tue, 03 May 2011 19:18:00 -0000 From: "Joseph S. Myers" To: Rainer Orth 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 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/msg00214.txt.bz2 On Tue, 3 May 2011, Rainer Orth wrote: > This patch broke Solaris 2/SPARC bootstrap which still uses > print_operand in sparc/sol2.h (ASM_OUTPUT_CALL). A bootstrap with the > obvious fix is currently running. > > 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). -- Joseph S. Myers joseph@codesourcery.com