Re: Completing toplevel libgcc move

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

"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

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University