[SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

[Joseph S. Myers]

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 
(<http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration> has notes dealing 
with the very narrow area of target macros in code built for the target).

-- 
Joseph S. Myers
joseph@codesourcery.com