More instantiation problems under hpux

[Gabriel Dos Reis]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

[...]

| It was decided that the built C++ limits header should match the C
| limits header not the actual FP hardware (the fact that the C limits
| header provided by an OS doesn't match the hardware might be
| considered a bug).  Under this observation, it must be understood that
| they are the published "worst-case" limits *(i.e. should be read as
| "you might not be able to store an FP with more precision or range"
| not "you will never see an FP value with more precision and/or range")
| the absolute limits that will be seen in all cases.*  The best example
| I can offer is FreeBSD running on i386.  By default, it is possible to
| get a float or double with far more precision and range than in the
| published header file unless it has been written to memory (in which
| case, by default, it is truncated to the published limits).  Of
| course, when this happens depends on compiler switches and exact code
| paths, etc.

[ Emphasis added ]

This description is a perfect transcript of the philosophy behing the
limit-thingies. 

| Can you confirm that this situation exists on hpux as well (and is not
| failing the same assertion for an alternate reason)?  Here is one was
| to do it:
| 
| Build istream_extractor_arith.exe using the rule in the log file.  Run
| it under gdb.  When it hits the assertion, go up to the stackframe
| with 'T t' in scope (I don't know if it varies per arch, but it should
| be one or two levels).  Note type T and value t.  Compare the value to
| the published limits file.  If you have the same issue I see, you
| should see what looks like a valid FP value (noting the value i, you
| can work out exactly what value t should have) yet outside the
| published C/C++ limits.  I suppose that operator>>() could refuse to
| return any values outside published limits for the related type.

Yes, on one hand I think operator>>() should refuse to return any
value outside publised limits for conformance reasons, and on the
other hand I think it /could/ be useful for some very special tasks
(e.g. system programming or such) to be able to get values beyond the
official limits if the hadware can handle them.  The latter option
should then be providded as an extension.  Benjamin, what is your take?

| If you see the same failure mode (thus confirming my theory beyond
| i386 and one OS),

I think architectures where register and memory precisions differ can be all
affected.  In the same theory, SPARCs should not be affected.  Any
confirmation or infirmation?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com