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 jos...@codesourcery.com
