This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- To: Alexandre Oliva <aoliva at redhat dot com>, Mark Mitchell <mark at codesourcery 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: David Edelsohn <dje at watson dot ibm dot com>
- Date: Wed, 01 Aug 2001 13:20:54 -0400
- 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, libstdc++ at gcc dot gnu dot org, Jan Hubicka <jh at suse dot cz>
>>>>> Alexandre Oliva writes:
Alexandre> On Jul 31, 2001, Richard Henderson <firstname.lastname@example.org> wrote:
>> On Tue, Jul 31, 2001 at 08:57:14PM -0400, David Edelsohn wrote:
>> That does seem to be the right approach.
Alexandre> I like it too. It just has to be updated so as to patch
Alexandre> include/Makefile.am instead of configure.in.
I am not exactly sure how to translate the try-catch block to the
Makefile (:^). Should the shell commands become the actions for the
std_limits.h target in the Makefile.am, including the testing?
I guess Stephen Webb's changes already have been moved to the
branch, so we cannot simply use my original patch there. Do we want to
try to use the "try running gen-num-limits and see if it fails" method on
the branch or switch completely to the pre-generated std_limits.h on the
branch as well?
I think that include/bits/limits_generic.h actually will cover all
normal targets. In order to have a single std_limits.h for all multilib
modes, I actually would have to ifdef the single "AIX" file for the 32 bit
vs 64 bit definitions of "long" anyway.
I see two needs / advantages to using target-specific
1) Unusual targets with unusual integer type sizes (PDP-11? Special
2) Avoid std_climits.h and std_cfloat.h dependency in std_limits.h.
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?