[build] Move unwinder to toplevel libgcc

Rainer Orth ro@CeBiTec.Uni-Bielefeld.DE
Mon Jun 20 15:47:00 GMT 2011


[Dropping the target maintainers from the Cc: since this isn't relevant
to the patch at hand.]

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

> On Mon, 20 Jun 2011, Rainer Orth wrote:
>
>> Certainly: your wiki entry gives a good overview.  For the moment, I'll
>> probably concentrate on the build side of things, though.  I may attack
>> gthr* stuff and fp-bit.[ch] next, both of which I can at least partially
>> test on my targets.
>
> fp-bit.[ch] has the interesting issue of FLOAT_BIT_ORDER_MISMATCH and 
> FLOAT_WORD_ORDER_MISMATCH being defined by makefile rules when it ought to 
> be possible to deduce that information from macros predefined by the 
> compiler.  (See what I said in 
> <http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02262.html> about the 
> meanings of those macros.)

Thanks for the pointer.  Those makefile rules are messy indeed, and what
prompted me to consider looking into this stuff: I just had a
mips-sgi-irix6.5 bootstrap break for me because the generated tp-bit.c
was corrupted, most likely because both multilibs created the file
quasi-simultaneously, mangling it in the process.

> dfp-bit.* and fixed-bit.* can probably move along with fp-bit.* (or 
> before, or after), and I don't think there are any complicated issues 
> around those files.

I'll have a look.  I may move them together if I have to touch many of
the same t-* files for that anyway.

	Rainer

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



More information about the Gcc-patches mailing list