[Bug fortran/95640] New: gfortran ieee_selected_real_kind returns 10

[Bug fortran/95640] New: gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

            Bug ID: 95640
           Summary: gfortran ieee_selected_real_kind returns 10
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90

program test
  use,intrinsic :: ieee_arithmetic

  print *, "     selected_real_kind(16) = ", selected_real_kind(16)
  print *, "ieee_selected_real_kind(16) = ", ieee_selected_real_kind(16)
end program test

Cray: 

> ftn test.f90
> ./a.out
     selected_real_kind(16) = 16
ieee_selected_real_kind(16) = 16

Intel:

> module swap PrgEnv-cray PrgEnv-intel
> ifort test.f90
> ./a.out
     selected_real_kind(16) = 16
ieee_selected_real_kind(16) = 16

Gfortran: 

> module swap PrgEnv-intel PrgEnv-gnu
> gfortran test.f90
> ./a.out
     selected_real_kind(16) = 10
ieee_selected_real_kind(16) = 10



The output from gfortran is problematic because ieee_selected_real_kind should
not return 10.   If the users want KIND=10 (i.e. the Intel-proprietary 80-bit
x87 floats), then they need to use selected_real_kind and not the IEEE version.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #1 from Bill Long <longb at cray dot com> ---
The main problem here is that selected_real_kind and ieee_selected_real_kind
have different specifications. The ieee_selected_real_kind requires a KIND
value corresponding to an IEEE floating format, whereas selected_real_kind is
only limited to formats supported by the processor, including non-ieee formats,
like the x87 80-bit format.  (Which, apparently, even the Intel compiler no
longer supports.) 

The expected output from gfortran would be

> gfortran test.f90
> ./a.out
     selected_real_kind(16) = 10
ieee_selected_real_kind(16) = 16

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-06-11
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed since at least GCC5, note the later returns

      selected_real_kind(16) =           10
 ieee_selected_real_kind(16) =           -1

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
         Depends on|                            |69101

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #0)
> > cat test.f90

> Gfortran: 
> 
> > module swap PrgEnv-intel PrgEnv-gnu
> > gfortran test.f90
> > ./a.out
>      selected_real_kind(16) = 10
> ieee_selected_real_kind(16) = 10
> 
> The output from gfortran is problematic because ieee_selected_real_kind
> should not return 10.   If the users want KIND=10 (i.e. the
> Intel-proprietary 80-bit x87 floats), then they need to use
> selected_real_kind and not the IEEE version.

IEEE-754 permits the extended double type (See 3.7 Extended and
extendable precisions).  I do not see in the Fortran standard that
the output from ieee_seleted_real_kind must select binary32,
binary64, or binary128.

That said, ieee_selected_real_kind is completely broken.
See PR69101.  I used to have patch that fixed this PR,
but never got around to committing it.  The patch attached
in 69101 is not correct.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101
[Bug 69101] [F03] IEEE_SELECTED_REAL_KIND is not generic

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jun 11, 2020 at 02:56:58PM +0000, kargl at gcc dot gnu.org wrote:
> 
> IEEE-754 permits the extended double type (See 3.7 Extended and
> extendable precisions).  I do not see in the Fortran standard that
> the output from ieee_seleted_real_kind must select binary32,
> binary64, or binary128.

Addendum 1, in case anyone cares.  Neither IEEE decimal64 nor
decimal128 can be returned as gfortran currently does not
support RADIX=10.

> That said, ieee_selected_real_kind is completely broken.
> See PR69101.  I used to have patch that fixed this PR,
> but never got around to committing it.  The patch attached
> in 69101 is not correct.

Addendum 2, I may have found my last working patch.  If I get
around to it, I might post it in the PR.

Addendum 3, F2018 has added at least ieee_fma.  gfortran does 
not support it.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #5 from Bill Long <longb at cray dot com> ---
The same user also submitted a bug about IEEE_FMA not being supported.  Is
there already a bug/rfe for that in the gcc bugzilla?

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #6 from Bill Long <longb at cray dot com> ---
(In reply to kargl from comment #3)
> (In reply to Bill Long from comment #0)
> > > cat test.f90
>  
> > Gfortran: 
> > 
> > > module swap PrgEnv-intel PrgEnv-gnu
> > > gfortran test.f90
> > > ./a.out
> >      selected_real_kind(16) = 10
> > ieee_selected_real_kind(16) = 10
> > 
> > The output from gfortran is problematic because ieee_selected_real_kind
> > should not return 10.   If the users want KIND=10 (i.e. the
> > Intel-proprietary 80-bit x87 floats), then they need to use
> > selected_real_kind and not the IEEE version.
> 
> IEEE-754 permits the extended double type (See 3.7 Extended and
> extendable precisions).  I do not see in the Fortran standard that
> the output from ieee_seleted_real_kind must select binary32,
> binary64, or binary128.
> 
> That said, ieee_selected_real_kind is completely broken.
> See PR69101.  I used to have patch that fixed this PR,
> but never got around to committing it.  The patch attached
> in 69101 is not correct.


The description in the Fortran standard for IEEE_SELECTED_REAL_KIND includes
"The result has a value equal to a value of the kind type parameter of an
ISO/IEC/IEEE 60559:2011 floating-point format..." This, in practice, amounts to
binary32, 64, 128 for RADIX=2 (the default).  The 80-bit x87 format is not part
of the quoted IEEE standard.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jun 11, 2020 at 04:12:57PM +0000, longb at cray dot com wrote:
> 
> --- Comment #5 from Bill Long <longb at cray dot com> ---
> The same user also submitted a bug about IEEE_FMA not being supported.  Is
> there already a bug/rfe for that in the gcc bugzilla?
> 

Not that I am aware of.

I had planned on looking at ieee support after 10.1 was released,
because it is a longer term effort.  The switch to git has caused
me to abandon that effort.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jun 11, 2020 at 04:21:25PM +0000, longb at cray dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
> 
> --- Comment #6 from Bill Long <longb at cray dot com> ---
> (In reply to kargl from comment #3)
> > (In reply to Bill Long from comment #0)
> > > > cat test.f90
> >  
> > > Gfortran: 
> > > 
> > > > module swap PrgEnv-intel PrgEnv-gnu
> > > > gfortran test.f90
> > > > ./a.out
> > >      selected_real_kind(16) = 10
> > > ieee_selected_real_kind(16) = 10
> > > 
> > > The output from gfortran is problematic because ieee_selected_real_kind
> > > should not return 10.   If the users want KIND=10 (i.e. the
> > > Intel-proprietary 80-bit x87 floats), then they need to use
> > > selected_real_kind and not the IEEE version.
> > 
> > IEEE-754 permits the extended double type (See 3.7 Extended and
> > extendable precisions).  I do not see in the Fortran standard that
> > the output from ieee_seleted_real_kind must select binary32,
> > binary64, or binary128.
> > 
> > That said, ieee_selected_real_kind is completely broken.
> > See PR69101.  I used to have patch that fixed this PR,
> > but never got around to committing it.  The patch attached
> > in 69101 is not correct.
> 
> 
> The description in the Fortran standard for IEEE_SELECTED_REAL_KIND includes
> "The result has a value equal to a value of the kind type parameter of an
> ISO/IEC/IEEE 60559:2011 floating-point format..." This, in practice, amounts to
> binary32, 64, 128 for RADIX=2 (the default).  The 80-bit x87 format is not part
> of the quoted IEEE standard.
> 

IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6):

  Five basic formats are defined in this clause:
    Three binary formats, with encodings in lengths of 32, 64, and 128 bits.
    Two decimal formats, with encodings in lengths of 64 and 128 bits.

  Additional arithmetic formats are recommended for extending these basic
  formats (see 3.7).

If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of
IEEE-754 basic formats, then it ought to say that.   Looks like a defect
in the Fortran standard.

If one looks into 3.7 (p. 14), it further recommends

  Language standards should define mechanisms supporting extendable
  precision for each supported radix.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jun 11, 2020 at 10:14:21AM -0700, Steve Kargl wrote:
> 
> IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6):
> 
>   Five basic formats are defined in this clause:
>     Three binary formats, with encodings in lengths of 32, 64, and 128 bits.
>     Two decimal formats, with encodings in lengths of 64 and 128 bits.
> 
>   Additional arithmetic formats are recommended for extending these basic
>   formats (see 3.7).
> 
> If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of
> IEEE-754 basic formats, then it ought to say that.   Looks like a defect
> in the Fortran standard.
> 
> If one looks into 3.7 (p. 14), it further recommends
> 
>   Language standards should define mechanisms supporting extendable
>   precision for each supported radix.
> 

I have asked on the J3 mailing list if Section 17 should
be restricted to the basic formats.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #9)
> On Thu, Jun 11, 2020 at 10:14:21AM -0700, Steve Kargl wrote:
> > 
> > IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6):
> > 
> >   Five basic formats are defined in this clause:
> >     Three binary formats, with encodings in lengths of 32, 64, and 128 bits.
> >     Two decimal formats, with encodings in lengths of 64 and 128 bits.
> > 
> >   Additional arithmetic formats are recommended for extending these basic
> >   formats (see 3.7).
> > 
> > If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of
> > IEEE-754 basic formats, then it ought to say that.   Looks like a defect
> > in the Fortran standard.
> > 
> > If one looks into 3.7 (p. 14), it further recommends
> > 
> >   Language standards should define mechanisms supporting extendable
> >   precision for each supported radix.
> > 
> 
> I have asked on the J3 mailing list if Section 17 should
> be restricted to the basic formats.

https://mailman.j3-fortran.org/pipermail/j3/2020-June/012148.html

Bill, is Malcolm's feedback sufficient?

This may fall under some processors may not support
the Intel-80 floating point format under Section 17
of the Standard.

I'll leave the bug report open for others to chime in.
Perhaps, others would rather not have a difference 
between gfortran and Cray and Intel compilers.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #11 from Bill Long <longb at cray dot com> ---
I checked with the Intel docs and the ia64 version of the compiler (what HPC
users use) does not support x87. 

Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an
error), to match the other compilers?

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #12 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #11)
> I checked with the Intel docs and the ia64 version of the compiler (what HPC
> users use) does not support x87. 
> 
> Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an
> error), to match the other compilers?

The types are set up in trans-type.c(gfc_init_kinds).  I
do not see an option that would disable querying for 
long_double_type_node.  In principle, one might be able
to define an option that prevents gfortran from see a
long_double_type_node. This should then disable REAL(10).

Looking at configure options, there is a --with-long-double-128
option but I've never used it.  Don't know if it will disable
REAL(10).  It appears linux specific.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jun 12, 2020 at 04:16:53AM +0000, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
> 
> --- Comment #12 from kargl at gcc dot gnu.org ---
> (In reply to Bill Long from comment #11)
> > I checked with the Intel docs and the ia64 version of the compiler (what HPC
> > users use) does not support x87. 
> > 
> > Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an
> > error), to match the other compilers?
> 
> The types are set up in trans-type.c(gfc_init_kinds).  I
> do not see an option that would disable querying for 
> long_double_type_node.  In principle, one might be able
> to define an option that prevents gfortran from see a
> long_double_type_node. This should then disable REAL(10).

I have confirmed that having an -fdisable-real10 option
could disable REAL(10) by commenting out the enumeration
of long_double_type_node, i.e.,

Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c   (revision 280157)
+++ gcc/fortran/trans-types.c   (working copy)
@@ -451,7 +451,7 @@ gfc_init_kinds (void)
        continue;
       if (mode != TYPE_MODE (float_type_node)
            && (mode != TYPE_MODE (double_type_node))
-           && (mode != TYPE_MODE (long_double_type_node))
+//         && (mode != TYPE_MODE (long_double_type_node))
 #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
            && (mode != TFmode)
 #endif

With a bit of work, someone could do

Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c   (revision 280157)
+++ gcc/fortran/trans-types.c   (working copy)
@@ -451,7 +451,7 @@ gfc_init_kinds (void)
        continue;
       if (mode != TYPE_MODE (float_type_node)
            && (mode != TYPE_MODE (double_type_node))
-           && (mode != TYPE_MODE (long_double_type_node))
+           && (!flag_disable_real10 || mode != TYPE_MODE
(long_double_type_node))
 #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
            && (mode != TFmode)
 #endif

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #14 from anlauf at gcc dot gnu.org ---
Why don't we simply set IEEE_SUPPORT_DATATYPE (1._10) to .false.?

use, intrinsic :: ieee_arithmetic
print *, ieee_support_datatype (1._10)
end

We currently print 'T'.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jun 12, 2020 at 03:33:20PM +0000, anlauf at gcc dot gnu.org wrote:
> --- Comment #14 from anlauf at gcc dot gnu.org ---
> Why don't we simply set IEEE_SUPPORT_DATATYPE (1._10) to .false.?
> 
> use, intrinsic :: ieee_arithmetic
> print *, ieee_support_datatype (1._10)
> end
> 
> We currently print 'T'.
> 

Because REAL(10) is a valid IEEE-754 format.  Some may want
REAL(10) because it is sufficient for their numerical problem
and it is done in hardware.  REAL(16) is a software implementation
(can you say slow).

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jun 11, 2020 at 10:40:29PM -0700, Steve Kargl wrote:
> On Fri, Jun 12, 2020 at 04:16:53AM +0000, kargl at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
> > 
> > --- Comment #12 from kargl at gcc dot gnu.org ---
> > (In reply to Bill Long from comment #11)
> > > I checked with the Intel docs and the ia64 version of the compiler (what HPC
> > > users use) does not support x87. 
> > > 
> > > Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an
> > > error), to match the other compilers?
> > 
> > The types are set up in trans-type.c(gfc_init_kinds).  I
> > do not see an option that would disable querying for 
> > long_double_type_node.  In principle, one might be able
> > to define an option that prevents gfortran from see a
> > long_double_type_node. This should then disable REAL(10).
> 
> I have confirmed that having an -fdisable-real10 option
> could disable REAL(10) by commenting out the enumeration
> of long_double_type_node, i.e.,
> 

Hmmm.  Well, my attempt to add an option failed.  I leave
this here in case someone else wants to unfix gfortran.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #13)
> With a bit of work, someone could do
> 
> Index: gcc/fortran/trans-types.c
> ===================================================================
> --- gcc/fortran/trans-types.c   (revision 280157)
> +++ gcc/fortran/trans-types.c   (working copy)
> @@ -451,7 +451,7 @@ gfc_init_kinds (void)
>         continue;
>        if (mode != TYPE_MODE (float_type_node)
>             && (mode != TYPE_MODE (double_type_node))
> -           && (mode != TYPE_MODE (long_double_type_node))
> +           && (!flag_disable_real10 || mode != TYPE_MODE
> (long_double_type_node))
>  #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
>             && (mode != TFmode)
>  #endif


It needs to be more complex than that as long double on most targets is NOT the
80bit (96bit or 128bit storage) IEEE FP type.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #18 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Jun 13, 2020 at 10:14:43AM +0000, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
> 
> --- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Steve Kargl from comment #13)
> > With a bit of work, someone could do
> > 
> > Index: gcc/fortran/trans-types.c
> > ===================================================================
> > --- gcc/fortran/trans-types.c   (revision 280157)
> > +++ gcc/fortran/trans-types.c   (working copy)
> > @@ -451,7 +451,7 @@ gfc_init_kinds (void)
> >         continue;
> >        if (mode != TYPE_MODE (float_type_node)
> >             && (mode != TYPE_MODE (double_type_node))
> > -           && (mode != TYPE_MODE (long_double_type_node))
> > +           && (!flag_disable_real10 || mode != TYPE_MODE
> > (long_double_type_node))
> >  #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
> >             && (mode != TFmode)
> >  #endif
> 
> 
> It needs to be more complex than that as long double on most
> targets is NOT the 80bit (96bit or 128bit storage) IEEE FP type.

Of course, this was just a test to see if it would work.
It does not.  

As gfortran's behavior conforms with the Fortran standard, I'm
inclined to close the bug report with INVALID.  But, I'm leaving
it open as someone else might find value in disabling REAL(10).
Now, if someone else closes the bug, I won't object.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #19 from Bill Long <longb at cray dot com> ---
On an ia64 Intel target that does not support x87 floating point, it seems that
having IEEE_SUPPORT_DATATYPE (1._10)  return .true. is as error.  If that is
fixed, will the rest of the issue fall into place?

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

--- Comment #20 from Bill Long <longb at cray dot com> ---
Original customer is asking about the status of this issue.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #21 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Bill Long from comment #19)
> On an ia64 Intel target that does not support x87 floating point, it seems
> that having IEEE_SUPPORT_DATATYPE (1._10)  return .true. is as error.  If
> that is fixed, will the rest of the issue fall into place?

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/ieee/ieee_arithmetic.F90#l1353
has:

#ifdef HAVE_GFC_REAL_10
SUPPORTMACRO(IEEE_SUPPORT_DATATYPE,10,.true.)
#endif

This could be unconditionally set to .false. The question is whether that makes
sense or not – or rather what condition needs to be fulfilled to have it set to
true or false.

(Likewise for all ieee_* functions, handled either in the library file or in
the compiler itself, like simplify_ieee_selected_real_kind.)

 * * *

Regarding REAL KIND=10, we have
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/trans-types.c#l463

      /* Let the kind equal the precision divided by 8, rounding up.  Again,
         this insulates the programmer from the underlying byte size.

         Also, it effectively deals with IEEE extended formats.  There, the
         total size of the type may equal 16, but it's got 6 bytes of padding
         and the increased size can get in the way of a real IEEE quad format
         which may also be supported by the target.

         We round up so as to handle IA-64 __floatreg (RFmode), which is an
         82 bit type.  Not to be confused with __float80 (XFmode), which is
         an 80 bit type also supported by IA-64.  So XFmode should come out
         to be kind=10, and RFmode should come out to be kind=11.  Egads.  */

      kind = (GET_MODE_PRECISION (mode) + 7) / 8;