This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- To: David Edelsohn <dje at watson dot ibm dot com>, Alexandre Oliva <aoliva at redhat dot com>, Gabriel Dos Reis <gdr at codesourcery dot com>, Phil Edwards <pedwards at disaster dot jaj dot com>
- Subject: Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Wed, 01 Aug 2001 10:34:08 -0700
- cc: Richard Henderson <rth at redhat dot com>, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Jan Hubicka <jh at suse dot cz>
> Do we actually need cpu/os-specific std_limits.h in most cases?
> Are we still making this too complicated by having to pre-generate
> gen-num-limits output for each target?
I perhaps wasn't clera. If the generic version is good enough for a
target it can use that. I had envisioned:
/somewhere/std_limits.h
#include <os_defines.h>
#ifdef OK_TO_USE_GENERIC_STUFF
#if BITS == 32
...
#elif BITS == 64
...
#endif
<generic stuff>
#else /* !OK_TO_USE_GENERIC_STUFF */
/* By this point os_defines.h will have done whatever it wanted to
do. */
#endif
So, the effort for a "normal" system is probably just to define BITS.
But, this supports a "weird" system if we run into one, too.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com