[Bug fortran/52153] REAL128 gives extended precision, not quad precision
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 --- Comment #9 from Steve Kargl --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 A. Kasahara changed: What|Removed |Added CC||latlon90180+gcc_bugzilla@gm ||ail.com --- Comment #8 from A. Kasahara --- Is there any progress on this? REAL128 of gfortran4.8 is still 10.
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 --- Comment #7 from Steve Kargl 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #6 from Steven Bosscher 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 --- Comment #4 from Steve Kargl 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 > 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;
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 --- Comment #3 from Steve Kargl 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-02-07 21:26:01 UTC --- > Yes, this is problem. So confirmed.
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
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