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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
Version|4.7.0   |4.7.1
 Resolution|--- |FIXED
   Target Milestone|--- |5.4

--- Comment #12 from kargl at gcc dot gnu.org ---
I did not realize that there was a PR about this issue.
I changed gfortran behavior to give what I expected 
user want in 7-branch prior to branching


r245255 | kargl | 2017-02-07 13:28:08 -0800 (Tue, 07 Feb 2017) | 6 lines

2017-02-04  Steven G. Kargl  

* trans-types.c (gfc_get_int_kind_from_width_isofortranen):  Choose
REAL type with the widest precision if two (or more) have the same
storage size.

I back ported the fix to both 5-branch (r24526) and
6-branch (r245259).  I don't have 5.xx installed, but
6, 7, and 8 give

% cat a.f90
use iso_fortran_env
real(real32)  a
real(real64)  b
real(real128) c
print *, kind(a), kind(b), kind(c)
print *, digits(a), digits(b),  digits(c)
end
% gfc6 -o z a.f90 && ./z
   4   8  16
  24  53 113
% gfc7 -o z a.f90 && ./z
   4   8  16
  24  53 113
% gfcx -o z a.f90 && ./z
   4   8  16
  24  53 113

So, I'm closing this as fixed (almost a year ago :-)

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

[a.vogt at fulguritus dot com]

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

Alexander Vogt  changed:

   What|Removed |Added

 CC||a.vogt at fulguritus dot com

--- Comment #11 from Alexander Vogt  ---
This is issue is still present on 6.1.1. Any chance that this gets fixed?
Anything I could do?

[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 +, 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 +, 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.

[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 +, 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

[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 +, 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 +, 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 +, 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;