This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)


>>>>> Alexandre Oliva writes:

Alexandre> On Jul 31, 2001, Richard Henderson <rth@redhat.com> wrote:
>> On Tue, Jul 31, 2001 at 08:57:14PM -0400, David Edelsohn wrote:
>>> http://gcc.gnu.org/ml/libstdc++/2001-06/msg00338.html

>> 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
std_limits.h:

1) Unusual targets with unusual integer type sizes (PDP-11?  Special
   embedded processors).

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?

David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]