[PATCH] libgfortran: Correct FP feature macro checks

Maciej W. Rozycki macro@linux-mips.org
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)
> end
> 
> 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)

  print *,h
  print *,e
end

This yields the following data produced for the real literals referred:

	.align 2
	.type	h.2, @object
	.size	h.2, 8
h.2:
	.long	-32769
	.long	0
	.align 2
	.type	e.1, @object
	.size	e.1, 8
e.1:
	.long	13568
	.long	0

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 
would expect:

h.2:
	.long	-32769
	.long	-1

(`e' seems right to me).

  Maciej


More information about the Gcc-patches mailing list