Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P)

[Joseph S. Myers]

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