On Wed, 25 Nov 2020, Tobias Burnus wrote:
> Does this solve all infinity issues? Or is there still code requiring it
> implicitly? From the previous exchange, it sounded as if there are still
> issues.
Infinity is the least of a problem, because as it turns out we have
numerous FP library functions in libgfortran that require explicit porting
to each FP format supported, like these settings:
xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
which need to be adjusted for the different representable ranges provided,
by the VAX format in this case. Fortunately the VAX encoding is quite
similar to IEEE 754 as far as the encodings of regular FP data are, but
the bias of the exponent is bumped up by 2, that is for example with the
double format using the VAX G-floating data type it is 1025 rather than
1023 -- 1 by the encoding of the exponent itself and 1 by the value of the
implicit mantissa bit. Some of my previous work on the libm part of glibc
can possibly be reused; see my other message here:
<https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560242.html>
BTW there's an interesting story available online regarding the VAX vs
IEEE 754 (Intel) FP format, which does explain the similarities:
<https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html>.
Maciej
