[SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

Hello.

  This patch removes obsolete PRINT_OPERAND, PRINT_OPERAND_ADDRESS and
PRINT_OPERAND_PUNCT_VALID_P macros from SPARC back end in the GCC and 
introduces equivalent TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS and 
TARGET_PRINT_OPERAND_PUNCT_VALID_P target hooks. 


   Bootstrapped and regression tested on sparc64-unknown-linux-gnu.

  OK to install?

        * config/sparc/sparc.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS,
        PRINT_OPERAND_PUNCT_VALID_P): Remove.
        * config/sparc/sparc-protos.h (print_operand): Remove declaration.
        * config/sparc/sparc.c (TARGET_PRINT_OPERAND_PUNCT_VALID_P,
        TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS): Define.
        (print_operand): Rename to...
        (sparc_print_operand): ...this. Make static. Adjust
        sparc_print_operand function call.
        (sparc_print_operand_punct_valid_p, sparc_print_operand_address): New
        functions.



Anatoly.

On 04/27/2011 11:13 AM, Anatoly Sokolov wrote:
>         * config/sparc/sparc.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS,
>         PRINT_OPERAND_PUNCT_VALID_P): Remove.
>         * config/sparc/sparc-protos.h (print_operand): Remove declaration.
>         * config/sparc/sparc.c (TARGET_PRINT_OPERAND_PUNCT_VALID_P,
>         TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS): Define.
>         (print_operand): Rename to...
>         (sparc_print_operand): ...this. Make static. Adjust
>         sparc_print_operand function call.
>         (sparc_print_operand_punct_valid_p, sparc_print_operand_address): New
>         functions.

Ok, except, 

> +  if(code == '#'

Space before (, re-indenting the rest of the condition to match.


r~

Richard Henderson <rth@redhat.com> writes:

> On 04/27/2011 11:13 AM, Anatoly Sokolov wrote:
>>         * config/sparc/sparc.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS,
>>         PRINT_OPERAND_PUNCT_VALID_P): Remove.
>>         * config/sparc/sparc-protos.h (print_operand): Remove declaration.
>>         * config/sparc/sparc.c (TARGET_PRINT_OPERAND_PUNCT_VALID_P,
>>         TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS): Define.
>>         (print_operand): Rename to...
>>         (sparc_print_operand): ...this. Make static. Adjust
>>         sparc_print_operand function call.
>>         (sparc_print_operand_punct_valid_p, sparc_print_operand_address): New
>>         functions.
>
> Ok, except, 
>
>> +  if(code == '#'
>
> Space before (, re-indenting the rest of the condition to match.

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???

	Rainer

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> 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

On Wed, 4 May 2011, Rainer Orth wrote:

> 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.

I've no idea whether they can be moved *at present*, but certainly the 
eventual aim should be to move them.

Before more macros are moved to files in libgcc/config I'd really rather 
the libgcc headers go in a separate libgcc_tm_file or similar, not 
included on the host and with the moved macros poisoned in the host 
system.h, to avoid the situation listed on that page of "RENAME_LIBRARY 
(in gcc/config/arm/symbian.h, otherwise moved to libgcc headers)" where a 
macro is only partly migrated to the libgcc headers but this partial state 
isn't obvious.  This has the advantage of avoiding the 
../../libgcc/config/ kludge in tm_file as well.

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Wed, 4 May 2011, Rainer Orth wrote:
>
>> 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.
>
> I've no idea whether they can be moved *at present*, but certainly the 
> eventual aim should be to move them.
>
> Before more macros are moved to files in libgcc/config I'd really rather 
> the libgcc headers go in a separate libgcc_tm_file or similar, not 
> included on the host and with the moved macros poisoned in the host 
> system.h, to avoid the situation listed on that page of "RENAME_LIBRARY 
> (in gcc/config/arm/symbian.h, otherwise moved to libgcc headers)" where a 
> macro is only partly migrated to the libgcc headers but this partial state 
> isn't obvious.  This has the advantage of avoiding the 
> ../../libgcc/config/ kludge in tm_file as well.

But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to
libgcc/config for all targets together?  How can you poison the macro
when a single target using it is left behind in gcc/config?

To actually test such a move, one had to setup complete
cross-environments for every affected target, which is way beyond what I
have the time and inclination to do.  This would mean that even targets
where the toplevel libgcc move could be completed and the maintainers
are motivated to do so are stalled until all other related ones are
done.  Doesn't seem highly desirable to me.

	Rainer

On Thu, 26 May 2011, Rainer Orth wrote:

> But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to
> libgcc/config for all targets together?  How can you poison the macro
> when a single target using it is left behind in gcc/config?

Nothing about the libgcc_tm.h implementation stops you moving a macro 
(that is not, in fact, used on the host) for only some targets if you 
don't poison it.  But I do think moving it for all targets together, and 
poisoning it, is much better.

> To actually test such a move, one had to setup complete
> cross-environments for every affected target, which is way beyond what I
> have the time and inclination to do.  This would mean that even targets
> where the toplevel libgcc move could be completed and the maintainers
> are motivated to do so are stalled until all other related ones are
> done.  Doesn't seem highly desirable to me.

Well, no, you post the patch (I'd guess all thirty or so target-only 
macros could be moved in a few hours, but moving them in smaller groups 
might be easier), test on the targets you can readily test on (building 
just cc1 and xgcc for the others), invite target maintainers (CC:ed) to 
test for other targets and seek approval to commit in maybe a week in the 
absence of problem reports from target maintainers.

I think completing the move for a particular macro is more meaningful, and 
has a better way to ensure the move doesn't regress, than completing it 
for a particular target.

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Thu, 26 May 2011, Rainer Orth wrote:
>
>> But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to
>> libgcc/config for all targets together?  How can you poison the macro
>> when a single target using it is left behind in gcc/config?
>
> Nothing about the libgcc_tm.h implementation stops you moving a macro 
> (that is not, in fact, used on the host) for only some targets if you 
> don't poison it.  But I do think moving it for all targets together, and 
> poisoning it, is much better.

Ok, I see.  It sounded to me as you wanted to somehow
discourage/prohibit those partial moves by policy.  Clearly achieving
some consistency here is a laudable goal and far better than having just
another incomplete transition that lingers forever.

>> To actually test such a move, one had to setup complete
>> cross-environments for every affected target, which is way beyond what I
>> have the time and inclination to do.  This would mean that even targets
>> where the toplevel libgcc move could be completed and the maintainers
>> are motivated to do so are stalled until all other related ones are
>> done.  Doesn't seem highly desirable to me.
>
> Well, no, you post the patch (I'd guess all thirty or so target-only 
> macros could be moved in a few hours, but moving them in smaller groups 
> might be easier), test on the targets you can readily test on (building 
> just cc1 and xgcc for the others), invite target maintainers (CC:ed) to 
> test for other targets and seek approval to commit in maybe a week in the 
> absence of problem reports from target maintainers.

Ok, that sounds doable.  AFAICS, the only ones of interest to my targets
are MD_UNWIND_SUPPORT and ENABLE_EXECUTE_STACK.  I'll probably do those
separately once the basic toplevel libgcc moves for Solaris, Tru64 UNIX
and IRIX are in.

Right now, I'm close for Solaris, but just noticed that
sparc/sol2-c[in].asm are used by sparc*-elf and sparc*-rtems, too, so
I'll have to deal with them as well before sparc*-*-solaris2* can be done.
The other two are pratically done, but rely on the Solaris move to go in
first.

> I think completing the move for a particular macro is more meaningful, and 
> has a better way to ensure the move doesn't regress, than completing it 
> for a particular target.

On the other hand, doing it per target has the advantage that you can
easily test the whole beast once, detect may cleanup opportunities, and
be done with it, rather than redoing the stuff on a per-macro basis.
But my targets above indicate that the number of macros per target may
actually be quite small.

	Rainer