[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #25 from Jerry DeLisle  ---
Closing after adjusting test case.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jan  1 19:01:24 2016
New Revision: 232029

URL: https://gcc.gnu.org/viewcvs?rev=232029=gcc=rev
Log:
2016-01-01  Jerry DeLisle  

PR libgfortran/68867
* gfortran.dg/default_format_denormal_2.f90: Fix the dg regular
expression.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/default_format_denormal_2.f90

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jan  1 18:13:17 2016
New Revision: 232027

URL: https://gcc.gnu.org/viewcvs?rev=232027=gcc=rev
Log:
2016-01-01  Jerry DeLisle  

PR libgfortran/68867
* gfortran.dg/default_format_denormal_2.f90: XFAIL for all
PowerPC.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/default_format_denormal_2.f90

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle  ---
(In reply to Bill Schmidt from comment #22)
> Jerry, thanks very much for investigating.  Given all the discussion here I
> agree with XFAILing this test for all powerpc.  However, it does appear to
> be one of those intermittent failures, so we'll have to put up with the
> occasional XPASS in our test results.

OK, I will set the test case. Occasional xpass seems odd to me. Let me know
when you see it, maybe its some unitialized bits???

[Bug libfortran/68867] numeric formatting problem in the fortran library

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Hm, but comment #8 from PR24685 indicates that this is clearly a regression. 
At that time Andrew Pinski asserted that this failure was restricted to Darwin,
and powerpc*-linux didn't fail the test.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #19)
> (In reply to Bill Seurer from comment #12)
> 
> > I checked with the revision previous to this patch and the revision for this
> > patch and the only differences were fmt_g0_7 succeeding and
> > default_format_denormal_2 failing.
> 
> Sorry about that Bill, I missed that in my testing, there are other tests
> already failing and I thought it was one of those.  All the patch did was
> decrease the width of the default format, in other words, the width chosen
> when none is specified by the user.  The patch changed nothing
> computationaly speaking.
> 
> I will take a look at this default_format_denormal_2 and see.  It should
> just be a minor adjustment of the test itself.  Let me know if you see any
> thing else.

OK, the failing of default_format_denormal_2 has nothing to do with this PR or
formatting for printing of floating point numbers.  It has to do with internal
representations.  I believe that Steve is correct and the test should be
XFailed for all PowerPC.  It is already { xfail powerpc*-apple-darwin* }

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  ---
(In reply to Bill Seurer from comment #12)

> I checked with the revision previous to this patch and the revision for this
> patch and the only differences were fmt_g0_7 succeeding and
> default_format_denormal_2 failing.

Sorry about that Bill, I missed that in my testing, there are other tests
already failing and I thought it was one of those.  All the patch did was
decrease the width of the default format, in other words, the width chosen when
none is specified by the user.  The patch changed nothing computationaly
speaking.

I will take a look at this default_format_denormal_2 and see.  It should just
be a minor adjustment of the test itself.  Let me know if you see any thing
else.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle  ---
Just to be double sure, I reverted my patch on the PowerPC I use for testing
and see that default_format_denormal_2.f90 fails regardless, so this is a
separate issue from this PR.  I think xfailing the test is valid since it
really is not a gfortran issue.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl  ---
On Wed, Dec 16, 2015 at 08:52:19PM +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
> 
> --- Comment #16 from Bill Schmidt  ---
> Hm, but comment #8 from PR24685 indicates that this is clearly a regression. 
> At that time Andrew Pinski asserted that this failure was restricted to 
> Darwin,
> and powerpc*-linux didn't fail the test.
> 

I prefer the sentiments of comment #2 from PR61399.

Perhaps, the test passed on powerpc*-linux because
it was a poorly defined test for that target and
ppc*linux got lucky.

But, I'll restate the obvious from my comment #15.

   Given the lack of details regarding the nature
   of the failure, xfailing the testcase is the
   only option.

Or in other words, we can't fix something that is
poorly defined.  So, the only solution is to sweep it
under the rug.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Bill Schmidt from comment #16)
> Hm, but comment #8 from PR24685 indicates that this is clearly a regression.
> At that time Andrew Pinski asserted that this failure was restricted to
> Darwin, and powerpc*-linux didn't fail the test.

That is because at the time (2006) powerpc*-linux* did not use 128bit long
double (double double); things changed around 2008 time frame.  So my comment
applies at the time I wrote it but the powerpc*-linux* targets changed after
that point.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[wschmidt at gcc dot gnu.org]

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

--- Comment #22 from Bill Schmidt  ---
Jerry, thanks very much for investigating.  Given all the discussion here I
agree with XFAILing this test for all powerpc.  However, it does appear to be
one of those intermittent failures, so we'll have to put up with the occasional
XPASS in our test results.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  ---
On Tue, Dec 15, 2015 at 06:03:55PM +, seurer at linux dot vnet.ibm.com
wrote:
> 
> FAIL: gfortran.dg/default_format_denormal_2.f90   -O0  execution test
> FAIL: gfortran.dg/default_format_denormal_2.f90   -O1  execution test
> FAIL: gfortran.dg/default_format_denormal_2.f90   -O2  execution test
> FAIL: gfortran.dg/default_format_denormal_2.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
> FAIL: gfortran.dg/default_format_denormal_2.f90   -O3 -g  execution test
> FAIL: gfortran.dg/default_format_denormal_2.f90   -Os  execution test
> 
> I checked with the revision previous to this patch and the revision for this
> patch and the only differences were fmt_g0_7 succeeding and
> default_format_denormal_2 failing.

% svn diff default_format_denormal_2.f90
Index: default_format_denormal_2.f90
===
--- default_format_denormal_2.f90   (revision 231661)
+++ default_format_denormal_2.f90   (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run { xfail powerpc*-apple-darwin* } }
+! { dg-do run { xfail powerpc*-*-* } }
 ! { dg-require-effective-target fortran_large_real }
 ! Test XFAILed on this platform because the system's printf() lacks
 ! proper support for denormalized long doubles. See PR24685

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jerry DeLisle  ---
Revision 231639 committed to trunk.

2015-12-14  Jerry DeLisle  

PR libfortran/pr68867
* io/write.c (set_fnode_default): For kind=16, set the decimal
precision
depending on the platform binary precision, 106 or 113.

https://gcc.gnu.org/viewcvs/gcc?view=revision=231639

Fixed on trunk.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #12 from Bill Seurer  ---
FAIL: gfortran.dg/fmt_g0_7.f08   -O0  execution test
FAIL: gfortran.dg/fmt_g0_7.f08   -O1  execution test
FAIL: gfortran.dg/fmt_g0_7.f08   -O2  execution test
FAIL: gfortran.dg/fmt_g0_7.f08   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/fmt_g0_7.f08   -O3 -g  execution test
FAIL: gfortran.dg/fmt_g0_7.f08   -Os  execution test

The above tests were fixed by the patch but the following tests now fail

FAIL: gfortran.dg/default_format_denormal_2.f90   -O0  execution test
FAIL: gfortran.dg/default_format_denormal_2.f90   -O1  execution test
FAIL: gfortran.dg/default_format_denormal_2.f90   -O2  execution test
FAIL: gfortran.dg/default_format_denormal_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/default_format_denormal_2.f90   -O3 -g  execution test
FAIL: gfortran.dg/default_format_denormal_2.f90   -Os  execution test

I checked with the revision previous to this patch and the revision for this
patch and the only differences were fmt_g0_7 succeeding and
default_format_denormal_2 failing.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  ---
On Tue, Dec 15, 2015 at 10:50:35PM +, seurer at linux dot vnet.ibm.com
wrote:
>
> Disabling the test will indeed make it "pass".  But it used to run OK and now
> no longer does so is disabling it the right solution?  Looking at pr23685 it
> looks like this has gone back and forth several times.
> 

pr23685 seems irrelevant.

Given the lack of details regarding the nature of the failure,
xfailing the testcase is the only option.

Noting that IBM's Knowledge center states

   Because of the storage method for the long double data type, more
   than one number can satisfy certain values that are available as
   macros. The representation of 128-bit long double numbers means
   that the following macros required by standard C in the values.h
   file do not have clear meaning:

   Number of bits in the mantissa (LDBL_MANT_DIG)
   Epsilon (LBDL_EPSILON)
   Maximum representable finite value (LDBL_MAX)

I suspect that this can be extended to IBM's double-double 
has issues with the representation for subnormal numbers.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[seurer at linux dot vnet.ibm.com]

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

--- Comment #14 from Bill Seurer  ---
Disabling the test will indeed make it "pass".  But it used to run OK and now
no longer does so is disabling it the right solution?  Looking at pr23685 it
looks like this has gone back and forth several times.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
A Patch has been submitted for approval.

https://gcc.gnu.org/ml/fortran/2015-12/msg00080.html

[Bug libfortran/68867] numeric formatting problem in the fortran library

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Removing the comment gives:
>
>   3  39 0.6919E-0001

> In the test case, I need to adjust the line;
>
> if (astring(2:2) /= '9') then
>
> to:
>
> if (astring(3:3) /= '9') then
>
> since the previous patch corrected a missing leading zero on the formatting.
>
> I will do so tomorrow.

I doubt that will fix the problem: it seems related to to a rounding issue with
REAL(16). Which REAL(16) is used? "IBM" one or float_128?

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #8)
> 
> I doubt that will fix the problem: it seems related to to a rounding issue
> with REAL(16). Which REAL(16) is used? "IBM" one or float_128?

True, it only fixes the work around code in fmt_g0_7.f08.  The underlying
problem is powerpc specific.  I do not know if it is we are using too may
default digits for kind=16?

[Bug libfortran/68867] numeric formatting problem in the fortran library

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Which platform are you using (gfortran -v)?
> 
> What is the output if you uncomment the line
> 
>   !print *, i, l, trim(astring)
> 
> ?

This is probably related to 

2015-11-22  Jerry DeLisle  

* io/write_float.def (output_float): Move block determining
room for leading zero to before checkng g0 formatting.

but William did not define "has been failing for a while now".

[Bug libfortran/68867] numeric formatting problem in the fortran library

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #3 from Bill Schmidt  ---
(In reply to kargl from comment #2)
> 
> This is probably related to 
> 
> 2015-11-22  Jerry DeLisle  
> 
> * io/write_float.def (output_float): Move block determining
> room for leading zero to before checkng g0 formatting.
> 
> but William did not define "has been failing for a while now".

I can confirm that this began failing with r230728, which is Jerry's patch.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from William Seurer  ---
Removing the comment gives:

   3  39 0.6919E-0001

Program aborted. Backtrace:
Aborted (core dumped)


It's been failing for at least a week; that's when I first noticed it.

I'm running on power8 little endian though it also fails on big endian.

gfortran -v:

Using built-in specs.
COLLECT_GCC=/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran7/../../gfortran
Target: powerpc64le-unknown-linux-gnu
Configured with: ...
Thread model: posix
gcc version 6.0.0 20151211 (experimental) [trunk revision 231573] (GCC)

[Bug libfortran/68867] numeric formatting problem in the fortran library

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Which platform are you using (gfortran -v)?

What is the output if you uncomment the line

!print *, i, l, trim(astring)

?

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #5 from Jerry DeLisle  ---
I will take this one.  I will run some tests and see what I can find out on
PowerPC,  Looks like rounding is a different.  Thanks for report.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Jerry DeLisle  ---
I have confirmed that fmt_g0_7.f08 fails.  It gets down to either xfailing the
test or modifying it to work with the rounding and precision of the particular
platform. I confirmed it on a Power7 platform.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
In the test case, I need to adjust the line;

if (astring(2:2) /= '9') then

to:

if (astring(3:3) /= '9') then

since the previous patch corrected a missing leading zero on the formatting.

I will do so tomorrow.