Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

"Joseph S. Myers" <joseph@codesourcery.com> 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 
> (<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).

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