New FreeBSD failures (somewhat) debugged

[Benjamin Kosnik]

> FAIL: 27_io/istream_extractor_arith.cc execution test
> assertion "is.fail()" failed: file "[...]/istream_extractor_arith.cc", line 539

Okay thanks.

> The problem, as debugged on i386-unknown-freebsd4.4, appears to be
> that digits_overflow is set to 39.  This means that st is set to
> "1234567890123456789012345678901234567890" which really doesn't
> overflow a float on this machine.  Why I do not know, but FreeBSD
> publishes limits in its system header files that do not exactly match
> the hardware.  This doesn't explain the solaris and hpux failure
> unless they have the same issue.  I suspect that they might not
> publish the tightest limits (or they might change when everything is
> done in a hardware register, etc).

I suspect the Solaris and HPUX issues are similar.

> BTW, the generated C++ limits header file should match the OS C header
> file even if that latter file is a white lie, no?

I have no idea. It seems like <limits> is trying  to match what the 
compiler says about the host, not necessarily what the "C" library says. 

Gaby? Help!!!

> The other two failures being spotted by nightly regression tests on
> FreeBSD are only seen on i386-unknown-freebsd5.0 (the only gdb
> installed there displays the dreaded ``Cannot handle DW_FORM_strp in
> DWARF reader'' startup message), not i386-unknown-freebsd4.4 or
> sparc-sun-solaris2.7.  I can report the assertion failures in case
> that is enough of a clue, but will not be able to debug it until I
> install the required gdb (sorry, won't happen until after new year).

Debugging on mainline is pretty much impossible right now. For some 
reason, gdb seems horribly confused about where in the stack frame it is, 
due to either compiler, debugger, or moon phase. Thus stepping over and 
into functions is problematic.

Try the branch, which has its issues but seems to get the basics right still.

-benjamin