| Message ID | 20170209183340.GA87711@troutmask.apl.washington.edu |
|---|---|
| State | New |
| Headers | show |
On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: > On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote: >> >> That being said, I think even with Steve's patch, it's not guaranteed >> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets, >> depending on the ABI you may get an IBM extended double (double-double >> or __ibm128) format. Although if IEEE binary128 is also available, >> with Steve's patch you should get that one has it has more precision >> that __ibm128. > > I do not have to a IBM POWER system, so cannot easily check the > effect of my patch. Well, me neither. (And as I haven't heard back from Laurent Guerby wrt. access to the GCC compile farm, my charlen->size_t patch is stuck, and most likely won't make it to GCC 7. Gah!) > I, however, suspect that it has no effect, > because IBM POWER probably only supports REAL(4), REAL(8), and > REAL(16). REAL(16) can have either double-double or IEEE-754 > semantics, but not both. Hmm, I think you're right. Per https://gcc.gnu.org/wiki/Ieee128PowerPC it seems that powerpc defines IFmode and KFmode in addition to TFmode, where TFmode is an alias to IFmode or KFmode where the choice depends on various compile options, ABI defaults etc. And further, in trans-types.c:gfc_init_kinds we use TFmode only if we also use libquadmath (if TFmode is different from long double). So I guess on POWER REAL(16) will be whatever the C long double type maps to. >> >> - Is this appropriate for stage 4? >> >> >> > Now that you remind of it, if we take the rules to the letter, no. >> > My opinion is that it should be accepted, in stage 4 or later. >> > But I don’t have a strong opinion about it either. >> >> I think it's Ok, the patch is quite small and unlikely to cause >> regressions. In particular since the ABI has already been bumped, now >> is a good time to piggyback other ABI changing stuff. >> >> Steve, please don't revert, but add a note to gcc-7/changes.html and >> the GFortran wiki. > > I may have had acces to the wiki at some point, but no longer can > login. For the gcc-7/changes.html, is the attached diff ok? Maybe prepend something like "The practical effect of this change is that ..." to the second paragraph? > Gerald, > is there a ChangeLog for wwwdocs/? > > -- > Steve > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
On 02/09/2017 12:40 PM, Janne Blomqvist wrote: > On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl > <sgk@troutmask.apl.washington.edu> wrote: >> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote: >>> >>> That being said, I think even with Steve's patch, it's not guaranteed >>> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets, >>> depending on the ABI you may get an IBM extended double (double-double >>> or __ibm128) format. Although if IEEE binary128 is also available, >>> with Steve's patch you should get that one has it has more precision >>> that __ibm128. >> >> I do not have to a IBM POWER system, so cannot easily check the >> effect of my patch. On IBM Power program foo use iso_fortran_env REAL(REAL128) x print '(3(I0,1X))', kind(x), digits(x), precision(x) end program foo $ gfc -static foo.f90 $ ./a.out 16 106 31 Same result as before the patch. Jerry
On Thu, Feb 09, 2017 at 07:35:11PM -0800, Jerry DeLisle wrote: > On 02/09/2017 12:40 PM, Janne Blomqvist wrote: > > On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl > > <sgk@troutmask.apl.washington.edu> wrote: > >> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote: > >>> > >>> That being said, I think even with Steve's patch, it's not guaranteed > >>> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets, > >>> depending on the ABI you may get an IBM extended double (double-double > >>> or __ibm128) format. Although if IEEE binary128 is also available, > >>> with Steve's patch you should get that one has it has more precision > >>> that __ibm128. > >> > >> I do not have to a IBM POWER system, so cannot easily check the > >> effect of my patch. > > On IBM Power > > program foo > use iso_fortran_env > REAL(REAL128) x > print '(3(I0,1X))', kind(x), digits(x), precision(x) > end program foo > > $ gfc -static foo.f90 > $ ./a.out > 16 106 31 > That is the double-double format. The gcc manual says that powerpc takes a -mfloat128 option (among others). This will probably give you 16 113 33.
On Thu, 9 Feb 2017, Steve Kargl wrote: > I may have had acces to the wiki at some point, but no longer can > login. For the gcc-7/changes.html, is the attached diff ok? Gerald, > is there a ChangeLog for wwwdocs/? the gcc-7/changes.html change looks good to me (wearing my web hat, I'll defer to you guys for the details ;-). We don't do ChangeLogs for wwwdocs, just use a simple statement as commit message (such as "Gfortran now defaults REAL(128) to..."). Gerald
On 02/09/2017 08:05 PM, Steve Kargl wrote: > On Thu, Feb 09, 2017 at 07:35:11PM -0800, Jerry DeLisle wrote: >> On 02/09/2017 12:40 PM, Janne Blomqvist wrote: >>> On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl >>> <sgk@troutmask.apl.washington.edu> wrote: >>>> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote: >>>>> >>>>> That being said, I think even with Steve's patch, it's not guaranteed >>>>> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets, >>>>> depending on the ABI you may get an IBM extended double (double-double >>>>> or __ibm128) format. Although if IEEE binary128 is also available, >>>>> with Steve's patch you should get that one has it has more precision >>>>> that __ibm128. >>>> >>>> I do not have to a IBM POWER system, so cannot easily check the >>>> effect of my patch. >> >> On IBM Power >> >> program foo >> use iso_fortran_env >> REAL(REAL128) x >> print '(3(I0,1X))', kind(x), digits(x), precision(x) >> end program foo >> >> $ gfc -static foo.f90 >> $ ./a.out >> 16 106 31 >> > > That is the double-double format. The gcc manual says that > powerpc takes a -mfloat128 option (among others). This will > probably give you 16 113 33. > $ gfc -static -mfloat128 foo.f90 $ ./a.out 16 106 31
On Fri, Feb 10, 2017 at 9:14 PM, Jerry DeLisle <jvdelisle@charter.net> wrote: > On 02/09/2017 08:05 PM, Steve Kargl wrote: >> >> On Thu, Feb 09, 2017 at 07:35:11PM -0800, Jerry DeLisle wrote: >>> >>> On 02/09/2017 12:40 PM, Janne Blomqvist wrote: >>>> >>>> On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl >>>> <sgk@troutmask.apl.washington.edu> wrote: >>>>> >>>>> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote: >>>>>> >>>>>> >>>>>> That being said, I think even with Steve's patch, it's not guaranteed >>>>>> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets, >>>>>> depending on the ABI you may get an IBM extended double (double-double >>>>>> or __ibm128) format. Although if IEEE binary128 is also available, >>>>>> with Steve's patch you should get that one has it has more precision >>>>>> that __ibm128. >>>>> >>>>> >>>>> I do not have to a IBM POWER system, so cannot easily check the >>>>> effect of my patch. >>> >>> >>> On IBM Power >>> >>> program foo >>> use iso_fortran_env >>> REAL(REAL128) x >>> print '(3(I0,1X))', kind(x), digits(x), precision(x) >>> end program foo >>> >>> $ gfc -static foo.f90 >>> $ ./a.out >>> 16 106 31 >>> >> >> That is the double-double format. The gcc manual says that >> powerpc takes a -mfloat128 option (among others). This will >> probably give you 16 113 33. >> > > $ gfc -static -mfloat128 foo.f90 > > $ ./a.out > 16 106 31 Hmm, fascinating. What about -mfloat128 -mcpu=power9 -mfloat128 -mabi=ieeelongdouble -mfloat128 -mcpu=power9 -mabi=ieeelongdouble ? (see https://gcc.gnu.org/wiki/Ieee128PowerPC for details)
On 02/10/2017 11:22 AM, Janne Blomqvist wrote: > On Fri, Feb 10, 2017 at 9:14 PM, Jerry DeLisle <jvdelisle@charter.net> wrote: >> On 02/09/2017 08:05 PM, Steve Kargl wrote: >>> >>> On Thu, Feb 09, 2017 at 07:35:11PM -0800, Jerry DeLisle wrote: >>>> >>>> On 02/09/2017 12:40 PM, Janne Blomqvist wrote: >>>>> >>>>> On Thu, Feb 9, 2017 at 8:33 PM, Steve Kargl >>>>> <sgk@troutmask.apl.washington.edu> wrote: >>>>>> >>>>>> On Thu, Feb 09, 2017 at 12:10:02PM +0200, Janne Blomqvist wrote: >>>>>>> >>>>>>> >>>>>>> That being said, I think even with Steve's patch, it's not guaranteed >>>>>>> to give you IEEE 754-2008 binary128. E.g. on IBM POWER targets, >>>>>>> depending on the ABI you may get an IBM extended double (double-double >>>>>>> or __ibm128) format. Although if IEEE binary128 is also available, >>>>>>> with Steve's patch you should get that one has it has more precision >>>>>>> that __ibm128. >>>>>> >>>>>> >>>>>> I do not have to a IBM POWER system, so cannot easily check the >>>>>> effect of my patch. >>>> >>>> >>>> On IBM Power >>>> >>>> program foo >>>> use iso_fortran_env >>>> REAL(REAL128) x >>>> print '(3(I0,1X))', kind(x), digits(x), precision(x) >>>> end program foo >>>> >>>> $ gfc -static foo.f90 >>>> $ ./a.out >>>> 16 106 31 >>>> >>> >>> That is the double-double format. The gcc manual says that >>> powerpc takes a -mfloat128 option (among others). This will >>> probably give you 16 113 33. >>> >> >> $ gfc -static -mfloat128 foo.f90 >> >> $ ./a.out >> 16 106 31 > > Hmm, fascinating. What about > > -mfloat128 -mcpu=power9 > -mfloat128 -mabi=ieeelongdouble > -mfloat128 -mcpu=power9 -mabi=ieeelongdouble > gcc112 is a power8 machine. $ gfc -static -mfloat128 -mcpu=power8 foo.f90 $ ./a.out 16 106 31 $ gfc -static -mfloat128 -mabi=ieeelongdouble foo.f90 gfc: warning: using IEEE extended precision long double f951: Warning: using IEEE extended precision long double $ ./a.out 16 113 33 $ gfc -static -mfloat128 -mcpu=power8 -mabi=ieeelongdouble foo.f90 gfc: warning: using IEEE extended precision long double f951: Warning: using IEEE extended precision long double $ ./a.out 16 113 33
On Fri, Feb 10, 2017 at 04:52:09PM -0800, Jerry DeLisle wrote: > > gcc112 is a power8 machine. > > $ gfc -static -mfloat128 -mcpu=power8 foo.f90 > $ ./a.out > 16 106 31 > > $ gfc -static -mfloat128 -mabi=ieeelongdouble foo.f90 > gfc: warning: using IEEE extended precision long double > f951: Warning: using IEEE extended precision long double > $ ./a.out > 16 113 33 > The warning looks strange. You've clearly asked the compiler to use IEEE 754, so why warn? Seems like a bug.
On Fri, Feb 10, 2017 at 05:00:26PM -0800, Steve Kargl wrote: > On Fri, Feb 10, 2017 at 04:52:09PM -0800, Jerry DeLisle wrote: > > > > gcc112 is a power8 machine. > > > > $ gfc -static -mfloat128 -mcpu=power8 foo.f90 > > $ ./a.out > > 16 106 31 > > > > $ gfc -static -mfloat128 -mabi=ieeelongdouble foo.f90 > > gfc: warning: using IEEE extended precision long double > > f951: Warning: using IEEE extended precision long double > > $ ./a.out > > 16 113 33 > > > > The warning looks strange. You've clearly asked the > compiler to use IEEE 754, so why warn? Seems like a > bug. I forgot to say "Thanks for checking what powerpc does."
Index: htdocs/gcc-7/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.63 diff -c -p -r1.63 changes.html *** htdocs/gcc-7/changes.html 7 Feb 2017 06:31:00 -0000 1.63 --- htdocs/gcc-7/changes.html 9 Feb 2017 18:26:35 -0000 *************** Fortran runtime error: Loop iterates inf *** 747,752 **** --- 747,765 ---- <li>Improved submodule support.</li> <li>Improved diagnostics (polymorphic results in pure functions).</li> + + <li><p>If more than one <code>REAL</code> type satified the storage + requirements for the ISO_FORTRAN_ENV <code>REAL128</code> entity, + prior versions of gfortran selected the <code>REAL</code> type + with narrowest precision. Gfortran now selects the <code>REAL</code> + type with the widest precision.</p> + + <p>On x86-64 class hardware, older versions of gfortran typically mapped + <code>REAL128</code> to <code>REAL(10)</code> except some options + (e.g., <code>-m96bit-long-double</code>) can cause it to be mapped to + <code>REAL(16)</code>. Now, <code>REAL128</code> is consistently + mapped to <code>REAL(16)</code>.</p> + </li> </ul> <!-- <h3 id="go">Go</h3> -->