[Bug fortran/52153] New: REAL128 gives extended precision, not quad precision

[Bug fortran/52153] New: REAL128 gives extended precision, not quad precision

[townsend at astro dot wisc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

             Bug #: 52153
           Summary: REAL128 gives extended precision, not quad precision
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: townsend@astro.wisc.edu


The REAL128 parameter defined in ISO_FORTRAN_ENV has the value 10, which
corresponds to extended precision. Should it not have a value 16, corresponding
to quad precision? 

As things currently stand, to obtain quad precision reals, I have to use
REAL(16) or REAL*16, which is non-portable; I'd rather use REAL(REAL128).

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

kargl at gcc dot gnu.org changed:

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

--- Comment #1 from kargl at gcc dot gnu.org 2012-02-07 19:41:39 UTC ---
(In reply to comment #0)
> 
> As things currently stand, to obtain quad precision reals, I have to use
> REAL(16) or REAL*16, which is non-portable; I'd rather use REAL(REAL128).

program foo
  use ISO_FORTRAN_ENV
  integer, parameter ::knd = selected_real_kind(p=30)
  real(REAL128) x
  real(knd) y
  print *, kind(x), kind(y)
end program foo

troutmask:sgk[208] gfc4x -o foo foo.f90 && ./foo
          10          16

Yes, this is problem.  However, you can use standard
conforming code to get at REAL(16)

-- 
steve

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-07
     Ever Confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-02-07 21:26:01 UTC ---
> Yes, this is problem.

So confirmed.

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-07 21:52:39 UTC ---
On Tue, Feb 07, 2012 at 09:26:01PM +0000, dominiq at lps dot ens.fr wrote:
> > Yes, this is problem.
> 
> So confirmed.
> 

Yes, and I'm currently regression testing a patch (should
be completed within the hour).

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-07 22:39:48 UTC ---
On Tue, Feb 07, 2012 at 09:52:39PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153
> 
> --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-07 21:52:39 UTC ---
> On Tue, Feb 07, 2012 at 09:26:01PM +0000, dominiq at lps dot ens.fr wrote:
> > > Yes, this is problem.
> > 
> > So confirmed.
> > 
> 
> Yes, and I'm currently regression testing a patch (should
> be completed within the hour).
> 

Regression tested without a problem, and it fixes the output
for the program in comment #2.

Index: trans-types.c
===================================================================
--- trans-types.c    (revision 183972)
+++ trans-types.c    (working copy)
@@ -257,12 +257,12 @@ gfc_get_real_kind_from_width_isofortrane

   /* Look for a kind with matching storage size.  */
   for (i = 0; gfc_real_kinds[i].kind != 0; i++)
-    if (int_size_in_bytes (gfc_get_real_type (gfc_real_kinds[i].kind)) ==
size)
+    if (gfc_real_kinds[i].kind == size)
       return gfc_real_kinds[i].kind;

   /* Look for a kind with larger storage size.  */
   for (i = 0; gfc_real_kinds[i].kind != 0; i++)
-    if (int_size_in_bytes (gfc_get_real_type (gfc_real_kinds[i].kind)) > size)
+    if (gfc_real_kinds[i].kind > size)
       return -2;

   return -1;

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

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

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-08 08:06:26 UTC ---
(In reply to comment #4)
> > Yes, and I'm currently regression testing a patch (should
> > be completed within the hour).
> 
> Regression tested without a problem, and it fixes the output
> for the program in comment #2.

Looks okay - and don't forget a test case. (Something like "if (REAL128 /= 16
.and. REAL128 > 0) call abort()" or similar, which can be combined with
-fdump-tree-original scan-tree ... 0 "abort".)

I assume we will have a lot of fun as soon as we allow selected_real_kind with
RADIX /= 2. (Such as decimal floating point numbers.)

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

Steven Bosscher <steven at gcc dot gnu.org> changed:

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

--- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> 2012-02-08 21:02:06 UTC ---
Did this feature already exist in GCC 4.6? If so, it would be good to mention
this change under the "Caveats" section in
http://gcc.gnu.org/gcc-4.7/changes.html

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-02-08 21:15:50 UTC ---
On Wed, Feb 08, 2012 at 09:02:06PM +0000, steven at gcc dot gnu.org wrote:
> 
> --- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> 2012-02-08 21:02:06 UTC ---
> Did this feature already exist in GCC 4.6?
> If so, it would be good to mention
> this change under the "Caveats" section in
> http://gcc.gnu.org/gcc-4.7/changes.html
> 

The feature and bug have been around since

------------------------------------------------------------------------
r147635 | fxcoudert | 2009-05-17 07:15:24 -0700 (Sun, 17 May 2009) | 14 lines

        * iso-fortran-env.def: Define INT8, INT16, INT32, INT64, REAL32,
        REAL64 and REAL128.
        ...
        * trans-types.c (get_typenode_from_name, get_int_kind_from_name,
        gfc_get_real_kind_from_width_isofortranenv): New functions.

so technically not a regression.  It also appears that the
addition was documented here

http://gcc.gnu.org/gcc-4.5/changes.html

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[latlon90180+gcc_bugzilla at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

A. Kasahara <latlon90180+gcc_bugzilla at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |latlon90180+gcc_bugzilla@gm
                   |                            |ail.com

--- Comment #8 from A. Kasahara <latlon90180+gcc_bugzilla at gmail dot com> ---
Is there any progress on this?
REAL128 of gfortran4.8 is still 10.

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 12, 2013 at 08:08:18AM +0000, latlon90180+gcc_bugzilla at gmail dot
com wrote:
> Is there any progress on this?
> REAL128 of gfortran4.8 is still 10.
> 

Need a short example.  gfortran has supported a 128-bit real type
for quite some time (since 4.6).

real(4) a
real(8) b
real(10) c
real(16) d
print '(4(I0,1X))', digits(a), digits(b), digits(c), digits(d)
end

% gfortran46 -o z a.f90 && ./z
24 53 53 113

PS: yes, the output is correct for real(10).  FreeBSD-i386's long double
only has 53-bits of precision.

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #9)
> On Mon, Aug 12, 2013 at 08:08:18AM +0000, latlon90180+gcc_bugzilla at gmail
> dot com wrote:
> > Is there any progress on this?
> > REAL128 of gfortran4.8 is still 10.
> > 
> 
> Need a short example.  gfortran has supported a 128-bit real type
> for quite some time (since 4.6).
> 
> real(4) a
> real(8) b
> real(10) c
> real(16) d
> print '(4(I0,1X))', digits(a), digits(b), digits(c), digits(d)
> end
> 
> % gfortran46 -o z a.f90 && ./z
> 24 53 53 113
> 
> PS: yes, the output is correct for real(10).  FreeBSD-i386's long double
> only has 53-bits of precision.

Ignore.  I should have read the audit trail first.