"Joseph S. Myers" <jos...@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
