[Bug libfortran/68867] numeric formatting problem in the fortran library
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
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 DeLislePR 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
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 DeLislePR 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
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
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
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
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
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
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
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
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
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
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 DeLislePR 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
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
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
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
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
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
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
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
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
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
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
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
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
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.