[PATCH] libgfortran: Correct FP feature macro checks
Maciej W. Rozycki
Wed Nov 25 22:02:37 GMT 2020
On Wed, 25 Nov 2020, Thomas Koenig wrote:
> > xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
> The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
> would have to be handled correctly, both for simplification in
> the front end and in the library.
> Does the program
> print *,HUGE(1.0)
> print *,EPSILON(1.0)
> print correct values?
Well, it does not link, for the somewhat unsurprising reason of a missing
libgfortran runtime. I have modified the program with whatever little
Fortran skills I gained a while ago to get something that can be parseable
for a human being in the assembly form:
real(8) :: h = HUGE(1.0)
real(8) :: e = EPSILON(1.0)
This yields the following data produced for the real literals referred:
.type h.2, @object
.size h.2, 8
.type e.1, @object
.size e.1, 8
which made me realise the NetBSD target defaults to the D-floating format
for some reason, which is significantly different in the range supported
from IEEE 754 double; specifically it has 1 sign bit, 8 exponent bits
(like IEEE 754 single) and 55 trailing significand bits.
So I am going to give up on giving this format any support, sorry (for
the VAX/Linux port I chose to use the G-floating format, which at least
gives some hope for interchangeability, even though I realise in some uses
the extra mantissa bits D-floating provides are useful).
In any case the output above does not appear exactly right to me as I
(`e' seems right to me).
More information about the Gcc-patches