jj@idris.id.dk (Jesper Joergensen [ris]) (01/14/90)
ATTN: Doug Lea
This note describes some problems with the MAX- and MINFLOAT definitions in
'values.h' for VAX computers (the default). The point is that the limits are
not as stringent as those defined by the compilers checking and the values in
my own '/usr/include/values.h'. The latter two however corresponds nicely to
each other.
I discovered the bad values the first time when I compiled libg++ version
1.35.0, where I got a compiler error and had to modify the supplied version of
'values.h'. I've been doing this ever since and now when I'm installing libg++
version 1.36.2 I still have the same problems. My environment is:
I am using: G++ version 1.36.3- (just installed it)
based on: GCC version 1.36
under: Ultrix V2.2-1 Worksystem V1.1 System #2
running on: DEC VAXstation 2000
Both GCC and G++ has been configured for BSD unix ('vax' parameter for
'config.gcc' and 'config.g++'), which is the closest equivalent to Ultrix
supported by GNU.
First lets take a look at the 'values.h' which comes with version 1.36.2 of
libg++, it defines the following values for vax computers (the default):
>> // #elif defined(vax)
>> // use vax versions by default -- they seem to be the most conservative
>> #else
>> #define MAXDOUBLE 1.701411834604692293e+38
>> #define MAXFLOAT ((float)MAXDOUBLE)
>> #define MINDOUBLE (2.938735877055718770e-39)
>> #define MINFLOAT ((float)MINDOUBLE)
This may look fairly correct, since the double and float types only differ in
precision and not in magnitude. BUT the definition of the CHECK_FLOAT_VALUE
macro in the target machine configuration file 'tm-vax.h' supplied by GCC and
inherited by G++ in the 'config' subdirectory says something else:
>> /* Check a `double' value for validity for a particular machine mode. */
>>
>> /* note that it is very hard to accidently create a number that fits in a
>> double but not in a float, since their ranges are almost the same */
>> #define CHECK_FLOAT_VALUE(mode, d) \
>> if ((mode) == SFmode) \
>> { \
>> if ((d) > 1.7014117331926443e+38) \
>> { error ("magnitude of constant too large for `float'"); \
>> (d) = 1.7014117331926443e+38; } \
>> else if ((d) < -1.7014117331926443e+38) \
>> { error ("magnitude of constant too large for `float'"); \
>> (d) = -1.7014117331926443e+38; } \
>> else if (((d) > 0) && ((d) < 2.9387358770557188e-39)) \
>> { warning ("`float' constant truncated to zero"); \
>> (d) = 0.0; } \
>> else if (((d) < 0) && ((d) > -2.9387358770557188e-39)) \
>> { warning ("`float' constant truncated to zero"); \
>> (d) = 0.0; } \
>> }
As you can see the maximal test values above are a bit smaller, starting at the
7th fractional digit. The minimum test values are larger, starting from the
16th fractional digit. The first of course is the worst, since the compiler
gives and ERROR on overflow, while only giving a warning on underflow.
Finally let's take a look at the '/usr/include/values.h' which is delivered as
part of Ultrix (my system), it says:
#if pdp11 || vax
#define MAXDOUBLE 1.701411834604692293e+38
#define MAXFLOAT ((float)1.701411733192644299e+38)
/* The following is kludged because the PDP-11 compilers botch the simple form.
The kludge causes the constant to be computed at run-time on the PDP-11,
even though it is still "folded" at compile-time on the VAX. */
#define MINDOUBLE (0.01 * 2.938735877055718770e-37)
#define MINFLOAT ((float)MINDOUBLE)
Here the maximum value seems OK, while the minimum is not acceptable to the
compiler. It looks like the values used by GCC is rounded up and looses the
last two digits from the original DEC Ultrix value.
CONCLUSION:
It is obvious that libg++ is wrong according to GCC's definition, so something
has to be done about that.
Whether GCC's definition is wrong according to the VAX ranges, as it seems to
be from the Ultrix DEC definitions (they actually made that computer), is a
problem that requires further research. Maybe you should pass a not to
Stallmann about it. If you'd like it I'll follow up on this problem by looking
at the definitions the VAX/VMS C compiler uses and by doing some calculations
(I have the VAX architecture handbook at hand every day and know these machines
nearly inside out).
Please mail me back as soon as possible, since I don't want to spend time on
this if you can correct the problem yourself.
Thanks
Jesper Jorgensen jj@idris.id.dk
Research associate
Department of Computer Science
Technical University of Denmark
DK-2800 Lyngby
DENMARK