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. 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.
> >> - 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? Gerald,
is there a ChangeLog for wwwdocs/?
--
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
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> -->
