[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-10 Summary|Wrong ouput using en edit |[4.8/4.9 Regression] Wrong |descriptor |ouput using en edit ||descriptor Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for 4.8.2 and trunk (4.9). 4.7.3 gives -444.44E-03
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Dominique d'Humieres changed: What|Removed |Added CC||jb at gcc dot gnu.org, ||jvdelisle at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- This likely due to r185433. This fixed by the following patch --- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0 +0100 +++ libgfortran/io/write_float.def2014-02-10 10:23:13.0 +0100 @@ -1215,8 +1211,8 @@ determine_en_precision (st_parameter_dt nbefore = 3 - nbefore; } int prec = f->u.real.d + nbefore; - if (dtp->u.p.current_unit->round_status != ROUND_UNSPECIFIED - && dtp->u.p.current_unit->round_status != ROUND_PROCDEFINED) + /* if (dtp->u.p.current_unit->round_status != ROUND_UNSPECIFIED + && dtp->u.p.current_unit->round_status != ROUND_PROCDEFINED) */ prec += 2 * len + 4; return prec; } For the following extended test write(*,"(en15.2)") -.4 write(*,"(rp,en15.2)") -.4 write(*,"(rc,en15.2)") -.4 write(*,"(rz,en15.2)") -.4 write(*,"(rd,en15.2)") -.4 write(*,"(en15.2)") -.6 write(*,"(en15.1)") -.4 end before the patch, the output is -444.40E-03 -444.40E-03 -444.44E-03 -444.44E-03 -444.45E-03 -444.50E-03 -444.0E-03 after the patch, it is -444.44E-03 -444.44E-03 -444.44E-03 -444.44E-03 -444.45E-03 -444.46E-03 -444.4E-03 Regtesting in progress. Note that the block - if (dtp->u.p.current_unit->round_status != ROUND_UNSPECIFIED - && dtp->u.p.current_unit->round_status != ROUND_PROCDEFINED) appears in several places in libgfortran/io/write_float.def and I fail to see the logic.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #3 from Dominique d'Humieres --- With the patch in comment 2, the test gfortran.dg/edit_real_1.f90 fails for the outputs #5, 6, and 13 5 12.873E+03z 6 12.344E-06z 13999.999E+00z instead of the expected outputs 5 12.874E+03z 6 12.345E-06z 13 1.000E+03z
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #4 from Dominique d'Humieres --- The regression reported in comment 3 disappears with the following patch --- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0 +0100 +++ libgfortran/io/write_float.def2014-02-10 11:35:55.0 +0100 @@ -326,7 +322,7 @@ output_float (st_parameter_dt *dtp, cons for IEEE 754, this ought to be round to nearest, ties to even, corresponding to the Fortran ROUND='NEAREST'. */ case ROUND_PROCDEFINED: - case ROUND_UNSPECIFIED: + /* case ROUND_UNSPECIFIED: */ case ROUND_ZERO: /* Do nothing and truncation occurs. */ goto skip; case ROUND_UP: @@ -338,6 +334,7 @@ output_float (st_parameter_dt *dtp, cons goto skip; goto updown; case ROUND_NEAREST: + case ROUND_UNSPECIFIED: /* Round compatible unless there is a tie. A tie is a 5 with all trailing zero's. */ i = nafter + nbefore; @@ -1215,8 +1212,8 @@ determine_en_precision (st_parameter_dt nbefore = 3 - nbefore; } int prec = f->u.real.d + nbefore; - if (dtp->u.p.current_unit->round_status != ROUND_UNSPECIFIED - && dtp->u.p.current_unit->round_status != ROUND_PROCDEFINED) + /* if (dtp->u.p.current_unit->round_status != ROUND_UNSPECIFIED + && dtp->u.p.current_unit->round_status != ROUND_PROCDEFINED) */ prec += 2 * len + 4; return prec; } >From the comment /* For processor defined and unspecified rounding we use snprintf to print the exact number of digits needed, and thus let snprintf handle the rounding. On system claiming support for IEEE 754, this ought to be round to nearest, ties to even, corresponding to the Fortran ROUND='NEAREST'. */ case ROUND_PROCDEFINED: case ROUND_UNSPECIFIED: case ROUND_ZERO: /* Do nothing and truncation occurs. */ I think it is wrong to handle ROUND_PROCDEFINED and ROUND_UNSPECIFIED as ROUND_ZERO.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #5 from Dominique d'Humieres --- While the patch in comment 4 fixed they PR, it was quite hawkish and did not explained the problem. After a deeper analysis it turns out that it is yet another "off by one bug" fixed by the following one liner: --- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0 +0100 +++ libgfortran/io/write_float.def2014-02-16 20:56:56.0 +0100 @@ -1204,7 +1200,7 @@ determine_en_precision (st_parameter_dt if (nprinted == -1) return -1; - int e = atoi (&buffer[5]); + int e = atoi (&buffer[4]); int nbefore; /* digits before decimal point - 1. */ if (e >= 0) nbefore = e % 3; as &buffer[5] does not include the sign of the exponent.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #6 from Dominique d'Humieres --- While preparing a test case, I have been hit by another snag!-( With the trunk and 4.8, the following test write(*,"(en15.2)") 98765. write(*,"(en15.3)") 9876.5 write(*,"(en15.1)") 987.65 write(*,"(en15.2)") 98.765 write(*,"(en15.3)") 9.8765 write(*,"(en15.1)") .98765 write(*,"(en15.2)") .098765 write(*,"(en15.3)") .0098765 write(*,"(en15.1)") .00098765 write(*,"(en15.2)") .98765 write(*,"(en15.2)") 98735. write(*,"(en15.3)") 9873.5 write(*,"(en15.1)") 987.35 write(*,"(en15.2)") 98.735 write(*,"(en15.3)") 9.8735 write(*,"(en15.1)") .98735 write(*,"(en15.2)") .098735 write(*,"(en15.3)") .0098735 write(*,"(en15.1)") .00098735 write(*,"(en15.2)") .98735 end gives the following output at run time 98.76E+03 9.876E+03 990.0E+00<- wrong 98.76E+00 9.876E+00 990.0E-03<- wrong 98.77E-03 9.876E-03 990.0E-06<- wrong 98.76E-06 98.73E+03 9.873E+03 990.0E+00<- wrong 98.73E+00 9.873E+00 990.0E-03<- wrong 98.73E-03 9.873E-03 990.0E-06<- wrong 98.73E-06 while 4.7 gives 98.77E+03 9.877E+03 987.7E+00 98.76E+00 9.877E+00 987.6E-03 98.77E-03 9.876E-03 987.7E-06 98.76E-06 98.74E+03 9.874E+03 987.3E+00 98.74E+00 9.873E+00 987.3E-03 98.73E-03 9.874E-03 987.4E-06 98.73E-06 The reason of these wrong code is due to the rounding of x between 0.95*10**d and 1.0*10**d to 1.*10**d. it follows that the exponent returned by 'nprinted = DTOA(y,0,tmp);' in '#define EN_PREC(x,y)' is the actual exponent 'e' plus one. I don't understand why this affects only the cases 'e%3==0' and I have no idea how this can be fixed -> any help welcomed!. Note that for the "working" cases I am not fully happy with the rounding: at least for 98765., 9876.5, 98735., and 9873.5 which have no rounding errors, I am expecting with round to even on tie: 98.76E+03, 98.76E+03, 98.74E+03, and 98.74E+03.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #7 from Dominique d'Humieres ---
The following patch fixes the issues reported in comment 6
--- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0
+0100
+++ libgfortran/io/write_float.def2014-02-18 09:59:04.0 +0100
@@ -1157,10 +1153,23 @@ OUTPUT_FLOAT_FMT_G(16,L)
#define EN_PREC(x,y)\
{\
-GFC_REAL_ ## x tmp;\
+GFC_REAL_ ## x tmp, one = 1.0;\
tmp = * (GFC_REAL_ ## x *)source;\
if (ISFINITE (y,tmp))\
- nprinted = DTOA(y,0,tmp);\
+ {\
+nprinted = DTOA(y,0,tmp);\
+int e = atoi (&buffer[4]); \
+if (buffer[1] == '1') \
+ {\
+tmp = (calculate_exp_ ## x (-e)) * tmp; \
+tmp = one - (tmp < 0 ? -tmp : tmp); \
+if (tmp > 0) \
+ e = e - 1; \
+ }\
+nbefore = e%3; \
+if (nbefore < 0) \
+ nbefore = 3 + nbefore; \
+ }\
else\
nprinted = -1;\
}\
@@ -1172,6 +1181,7 @@ determine_en_precision (st_parameter_dt
int nprinted;
char buffer[10];
const size_t size = 10;
+ int nbefore; /* digits before decimal point - 1. */
switch (len)
{
@@ -1204,16 +1214,6 @@ determine_en_precision (st_parameter_dt
if (nprinted == -1)
return -1;
- int e = atoi (&buffer[5]);
- int nbefore; /* digits before decimal point - 1. */
- if (e >= 0)
-nbefore = e % 3;
- else
-{
- nbefore = (-e) % 3;
- if (nbefore != 0)
-nbefore = 3 - nbefore;
-}
int prec = f->u.real.d + nbefore;
if (dtp->u.p.current_unit->round_status != ROUND_UNSPECIFIED
&& dtp->u.p.current_unit->round_status != ROUND_PROCDEFINED)
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.3
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #2) > This likely due to r185433. This fixed by the following patch ... (In reply to Dominique d'Humieres from comment #7) > The following patch fixes the issues reported in comment 6 Dominique, Jerry: What's the status of those patch set? Can this be wrapped up as patch for GCC 4.9? If so, it should be done soon.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #9 from Jerry DeLisle --- I have reviewed and tested the patch from comment #7 on x86-64 with -m32 and -m64 and I think its ready. Dominique mentioned to possibly add a volatile. I have not tested on the other platforms. I can commit as soon as I get the go signal.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #10 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 8 06:04:34 2014 New Revision: 208423 URL: http://gcc.gnu.org/viewcvs?rev=208423&root=gcc&view=rev Log: 2014-03-08 Dominique d'Humieres PR libgfortran/60128 * io/write_float.def (output_float): Remove unused variable nzero_real. Replace a double space with a single one. (determine_en_precision): Fix wrong handling of the EN format. PR libfortran/60128 * gfortran.dg/fmt_en.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_en.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #11 from Jerry DeLisle --- Author: jvdelisle Date: Sun Mar 16 00:18:21 2014 New Revision: 208603 URL: http://gcc.gnu.org/viewcvs?rev=208603&root=gcc&view=rev Log: 2014-03-15 Dominique d'Humieres Backport from mainline PR libgfortran/60128 * io/write_float.def (output_float): Remove unused variable nzero_real. Replace a double space with a single one. (determine_en_precision): Fix wrong handling of the EN format. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/write_float.def
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Sun Mar 16 00:35:19 2014 New Revision: 208604 URL: http://gcc.gnu.org/viewcvs?rev=208604&root=gcc&view=rev Log: 2014-03-15 Dominique d'Humieres Backport from mainline PR libfortran/60128 * gfortran.dg/fmt_en.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_en.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jerry DeLisle --- Fixed on trunk and 4.8. Closing
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #14 from Rainer Orth --- The new testcase FAILs on Solaris 9/x86 on mainline: FAIL: gfortran.dg/fmt_en.f90 -O0 execution test FAIL: gfortran.dg/fmt_en.f90 -O1 execution test FAIL: gfortran.dg/fmt_en.f90 -O2 execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -g execution test FAIL: gfortran.dg/fmt_en.f90 -Os execution test E.g. at -O0: (en15.0)999.E-03 expected: 1.E+00 (en15.0) 9.E+00 expected: 10.E+00 (en15.0) 99.E+00 expected: 100.E+00 (en15.0)999.E+00 expected: 1.E+03 (en15.0) 9.E+00 expected: 10.E+00 (en15.0) 9.E+00 expected: 10.E+00 (en15.0) 99.E+00 expected: 100.E+00 (en15.0) 99.E+00 expected: 100.E+00 (en15.0)999.E+00 expected: 1.E+03 (en15.0)999.E+00 expected: 1.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.2)9.99E+03 expected:10.00E+03 (en15.3) 9.999E+03 expected: 10.000E+03 (en15.1) 9.4E+00 expected: 9.5E+00 (en15.1)99.9E-03 expected:100.0E-03 (en15.1) 9.9E-03 expected: 10.0E-03 (en15.1) 999.9E-06 expected: 1.0E-03 (en15.0) -999.E-03 expected: -1.E+00 (en15.0) -9.E+00 expected: -10.E+00 (en15.0)-99.E+00 expected:-100.E+00 (en15.0) -999.E+00 expected: -1.E+03 (en15.0) -9.E+00 expected: -10.E+00 (en15.0) -9.E+00 expected: -10.E+00 (en15.0)-99.E+00 expected:-100.E+00 (en15.0)-99.E+00 expected:-100.E+00 (en15.0) -999.E+00 expected: -1.E+03 (en15.0) -999.E+00 expected: -1.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.2) -9.99E+03 expected: -10.00E+03 (en15.3) -9.999E+03 expected: -10.000E+03 (en15.1)-9.4E+00 expected: -9.5E+00 (en15.1) -99.9E-03 expected: -100.0E-03 (en15.1)-9.9E-03 expected:-10.0E-03 (en15.1) -999.9E-06 expected: -1.0E-03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.2) 98.73E+03 expected:98.74E+03 (en15.3) 9.873E+03 expected:9.874E+03 (en15.1)93.7E-03 expected: 93.8E-03 (en15.2) 46.87E-03 expected:46.88E-03 (en15.3) 23.437E-03 expected: 23.438E-03 (en15.6)2.929687E-03 expected: 2.929688E-03 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.2) -98.73E+03 expected: -98.74E+03 (en15.3) -9.873E+03 expected: -9.874E+03 (en15.1) -93.7E-03 expected:-93.8E-03 (en15.2) -46.87E-03 expected: -46.88E-03 (en15.3) -23.437E-03 expected: -23.438E-03 (en15.6) -2.929687E-03 expected:-2.929688E-03 Program aborted. Backtrace: #0 0xB5C343F6 #1 0xB5C35D66 #2 0xB5CF6223 #3 0x8051C27 in MAIN__ at fmt_en.f90:? Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #15 from Dominique d'Humieres --- What is the output of write(*,"(en15.1)") 9.4905 end ? If it is 9.4, it means that your snprintf is not rounding to nearest but to zero.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from Dominique d'Humieres --- > What is the output of > > write(*,"(en15.1)") 9.4905 > end > > ? If it is 9.4, it means that your snprintf is not rounding to nearest but to > zero. No, that's not it: I get 9.5E+00 Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #17 from Dominique d'Humieres --- Could your repeat the test for write(*,"(en15.1)") 9.4905_8 end write(*,"(en15.1)") 9.4905_10 end and write(*,"(en15.1)") 9.4905_16 end ?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Dominique d'Humieres --- > Could your repeat the test for > > write(*,"(en15.1)") 9.4905_8 > end 9.5E+00 > write(*,"(en15.1)") 9.4905_10 > end 9.5E+00 > write(*,"(en15.1)") 9.4905_16 > end 9.4E+00 Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #19 from Dominique d'Humieres --- > > write(*,"(en15.1)") 9.4905_16 > > end > > 9.4E+00 So the test fails due to a bug in the rounding of real(16) in your lib. Do you have any idea about how the tests for real(16) can be skipped on Solaris 9/x86?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #20 from Jerry DeLisle --- We can xfail the test case if we are certain of the problem.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #21 from Dominique d'Humieres --- > We can xfail the test case if we are certain of the problem. What I don't see is how to xfail only some tests for real(16). Anyway, Rainer could open a new PR for the solaris issue and close this one as FIXED?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #19 from Dominique d'Humieres --- >> > write(*,"(en15.1)") 9.4905_16 >> > end >> >> 9.4E+00 > > So the test fails due to a bug in the rounding of real(16) in your lib. Do you > have any idea about how the tests for real(16) can be skipped on Solaris > 9/x86? I'm not sure that's the problem: AFAICS snprintf is only used by io/write_float.def (output_float:734) to print the exponent, the rest is handled by quadmath_snprintf. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #23 from Dominique d'Humieres --- > I'm not sure that's the problem: AFAICS snprintf is only used by > io/write_float.def (output_float:734) to print the exponent, the rest is > handled by quadmath_snprintf. The failing tests assume round to nearest. AFAICT quadmath_snprintf round to zero on solaris.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #24 from Dominique d'Humieres --- Rainer, can you test the following patch? --- _clean/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-04 17:51:04.0 +0100 +++ work/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-18 18:08:22.0 +0100 @@ -128,6 +128,9 @@ contains else if (i == 3) then write(s, fmt) real(x,kind=j(3)) else if (i == 4) then +! skip if real(16) are not rounded to nearest (Solaris 9/x86) +write(s, '(F3.1)') real(9.4905,kind=j(4)) +if (s /= '9.5') exit write(s, fmt) real(x,kind=j(4)) end if n_tst = n_tst + 1
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #25 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #21) > > We can xfail the test case if we are certain of the problem. > > What I don't see is how to xfail only some tests for real(16). Anyway, > Rainer could open a new PR for the solaris issue and close this one as FIXED? What we should do is break the test case into two test cases one for quad16 and the other for the rest. Then we XFAIL the quad16 one for solaris. I think we also need a new PR that is platform specific. There may be some configury magic that needs to be done for Solaris to work correctly.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #24 from Dominique d'Humieres --- > Rainer, > > can you test the following patch? > > --- _clean/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-04 > 17:51:04.0 +0100 > +++ work/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-18 18:08:22.0 > +0100 > @@ -128,6 +128,9 @@ contains >else if (i == 3) then > write(s, fmt) real(x,kind=j(3)) >else if (i == 4) then > +! skip if real(16) are not rounded to nearest (Solaris 9/x86) > +write(s, '(F3.1)') real(9.4905,kind=j(4)) > +if (s /= '9.5') exit > write(s, fmt) real(x,kind=j(4)) >end if >n_tst = n_tst + 1 This passes on both i386-pc-solaris2.9 and i386-pc-solaris2.11. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Jerry DeLisle --- > (In reply to Dominique d'Humieres from comment #21) >> > We can xfail the test case if we are certain of the problem. >> >> What I don't see is how to xfail only some tests for real(16). Anyway, >> Rainer could open a new PR for the solaris issue and close this one as FIXED? > > What we should do is break the test case into two test cases one for quad16 > and > the other for the rest. Then we XFAIL the quad16 one for solaris. I think we Agreed, that's better than silently exiting a test in certain conditions, making it seem that it works while it actually doesn't. > also need a new PR that is platform specific. There may be some configury > magic that needs to be done for Solaris to work correctly. I've now filed PR fortran/60582. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #28 from Dominique d'Humieres --- >> > What we should do is break the test case into two test cases one for >> > quad16 and >> > the other for the rest. Then we XFAIL the quad16 one for solaris. I >> > think we >> >> Agreed, that's better than silently exiting a test in certain >> conditions, making it seem that it works while it actually doesn't. > > For the later remark, this can be handled with something such as the following > patch: [...] Works for me, although in the XFAIL case the output in gfortran.sum looks a bit strange: XFAIL: gfortran.dg/fmt_en.f90 -O0 output pattern test, is real(16) are not rou nded to nearest , should match no test skipped I'd try to keep it on a single line. Now the test is ok on i386-pc-solaris2.9 (XFAILs as expected) and i386-pc-solaris2.11 (everything PASSes). > Splitting the test along the real kinds is difficult to do, as some platforms > don't have real(10) (e.g., powerpc). If the test has to be split, I'ld prefer > to split it along the line 'wrong outputs' (comment 0 and 6)/ 'rounding tests' > (those failing on solaris). That's clearly up to the Fortran maintainers to decide. Thanks. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #30 from Dominique d'Humieres ---
Is the following patch better?
--- ../_clean/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-08
10:02:08.0 +0100
+++ gcc/testsuite/gfortran.dg/fmt_en.f902014-03-20 16:34:03.0 +0100
@@ -2,8 +2,41 @@
! PR60128 Invalid outputs with EN descriptors
! Test case provided by Walt Brainerd.
program pr60128
-implicit none
+use ISO_FORTRAN_ENV
+implicit none
+integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
+logical :: l_skip(4) = .false.
+integer :: i
integer :: n_tst = 0, n_cnt = 0
+character(len=20) :: s
+
+open (unit = 10, file = 'fmt_en.res')
+! Check that the default rounding mode is to nearest and to even on tie.
+do i=1,size(real_kinds)
+ if (i == 1) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(1)), &
+ real(9.4905,kind=j(1)), &
+ real(9.5,kind=j(1)), real(8.5,kind=j(1))
+ else if (i == 2) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(2)), &
+ real(9.4905,kind=j(2)), &
+ real(9.5,kind=j(2)), real(8.5,kind=j(2))
+ else if (i == 3) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(3)), &
+ real(9.4905,kind=j(3)), &
+ real(9.5,kind=j(3)), real(8.5,kind=j(3))
+ else if (i == 4) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(4)), &
+ real(9.4905,kind=j(4)), &
+ real(9.5,kind=j(4)), real(8.5,kind=j(4))
+ end if
+ if (s /= '-9.5 9.5 10. 8.') then
+l_skip(i) = .true.
+print "('Unsupported rounding for real(',i0,')')", j(i)
+write (10, "('Unsupported rounding for real(',i0,')')") j(i)
+ end if
+end do
+
! Original test.
call checkfmt("(en15.2)", -.4,"-444.44E-03")
@@ -112,15 +145,13 @@ implicit none
contains
subroutine checkfmt(fmt, x, cmp)
-use ISO_FORTRAN_ENV
implicit none
-integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
integer :: i
character(len=*), intent(in) :: fmt
real, intent(in) :: x
character(len=*), intent(in) :: cmp
-character(len=20) :: s
do i=1,size(real_kinds)
+ if (l_skip(i)) cycle
if (i == 1) then
write(s, fmt) real(x,kind=j(1))
else if (i == 2) then
@@ -139,3 +170,5 @@ contains
end subroutine
end program
+! { dg-final { scan-file-not fmt_en.res "Unsupported rounding" { xfail
i?86-*-solaris2.9* } } }
+! { dg-final { cleanup-saved-temps } }
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #30 from Dominique d'Humieres --- > Is the following patch better? It was a bit confusing at first glimpse, but fine. Thanks. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #32 from Dominique d'Humieres --- > It was a bit confusing at first glimpse, but fine. ???
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #33 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #32 from Dominique d'Humieres --- >> It was a bit confusing at first glimpse, but fine. > > ??? I ran the test on Solaris 9 and 11 and looked at the resulting .sum files. Seeing the Unsupported rounding entries on Solaris 11 (any platform without the rounding issue actually) seemed strange/backwards at first (double negation) until I understood how it's done. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #34 from Dominique d'Humieres ---
> I ran the test on Solaris 9 and 11 and looked at the resulting .sum
> files. Seeing the Unsupported rounding entries on Solaris 11 (any
> platform without the rounding issue actually) seemed strange/backwards
> at first (double negation) until I understood how it's done.
I agree that direct logic is better than double negation. With the following
patch
--- ../_clean/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-08
10:02:08.0 +0100
+++ gcc/testsuite/gfortran.dg/fmt_en.f902014-03-20 18:26:49.0 +0100
@@ -2,8 +2,40 @@
! PR60128 Invalid outputs with EN descriptors
! Test case provided by Walt Brainerd.
program pr60128
-implicit none
+use ISO_FORTRAN_ENV
+implicit none
+integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
+logical :: l_skip(4) = .false.
+integer :: i
integer :: n_tst = 0, n_cnt = 0
+character(len=20) :: s
+
+open (unit = 10, file = 'fmt_en.res')
+! Check that the default rounding mode is to nearest and to even on tie.
+do i=1,size(real_kinds)
+ if (i == 1) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(1)), &
+ real(9.4905,kind=j(1)), &
+ real(9.5,kind=j(1)), real(8.5,kind=j(1))
+ else if (i == 2) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(2)), &
+ real(9.4905,kind=j(2)), &
+ real(9.5,kind=j(2)), real(8.5,kind=j(2))
+ else if (i == 3) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(3)), &
+ real(9.4905,kind=j(3)), &
+ real(9.5,kind=j(3)), real(8.5,kind=j(3))
+ else if (i == 4) then
+write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(4)), &
+ real(9.4905,kind=j(4)), &
+ real(9.5,kind=j(4)), real(8.5,kind=j(4))
+ end if
+ if (s /= '-9.5 9.5 10. 8.') then
+l_skip(i) = .true.
+print "('Unsupported rounding for real(',i0,')')", j(i)
+ end if
+end do
+
! Original test.
call checkfmt("(en15.2)", -.4,"-444.44E-03")
@@ -109,18 +141,18 @@ implicit none
!print *, n_tst, n_cnt
if (n_cnt /= 0) call abort
+if (all(.not. l_skip)) write (10, *) "All kinds rounded to nearest"
+close (10)
contains
subroutine checkfmt(fmt, x, cmp)
-use ISO_FORTRAN_ENV
implicit none
-integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
integer :: i
character(len=*), intent(in) :: fmt
real, intent(in) :: x
character(len=*), intent(in) :: cmp
-character(len=20) :: s
do i=1,size(real_kinds)
+ if (l_skip(i)) cycle
if (i == 1) then
write(s, fmt) real(x,kind=j(1))
else if (i == 2) then
@@ -139,3 +171,5 @@ contains
end subroutine
end program
+! { dg-final { scan-file fmt_en.res "All kinds rounded to nearest" { xfail
i?86-*-solaris2.9* } } }
+! { dg-final { cleanup-saved-temps } }
the gfortran.sum contains
...
PASS: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest
...
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #34 from Dominique d'Humieres --- >> I ran the test on Solaris 9 and 11 and looked at the resulting .sum >> files. Seeing the Unsupported rounding entries on Solaris 11 (any >> platform without the rounding issue actually) seemed strange/backwards >> at first (double negation) until I understood how it's done. > > I agree that direct logic is better than double negation. With the following > patch [...] > the gfortran.sum contains > > ... > PASS: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest > ... Even better. Tested again on i386-pc-solaris2.9 and i386-pc-solaris2.11. Thanks. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #36 from Jerry DeLisle --- Looks Good! I will commit the change in Comment #34 soon.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #37 from Jerry DeLisle --- Author: jvdelisle Date: Mon Mar 24 00:29:43 2014 New Revision: 208780 URL: http://gcc.gnu.org/viewcvs?rev=208780&root=gcc&view=rev Log: 2014-03-23 Dominique d'Humieres PR libfortran/60128 * gfortran.dg/fmt_en.f90: Update test. XFAIL for i?86-*-solaris2.9*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_en.f90
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #38 from John David Anglin --- gfortran.dg/fmt_en.f90 tests fail on hppa*-*-hpux11* (4.8 and 4.9): (en15.0) 9.E+03 expected: 10.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.1) 987.7E+03 expected:987.6E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.3) 9.877E+03 expected:9.876E+03 (en15.1)31.3E-03 expected: 31.2E-03 (en15.2) 15.63E-03 expected:15.62E-03 (en15.3) 7.813E-03 expected:7.812E-03 (en15.3) 976.563E-06 expected: 976.562E-06 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.1) -987.7E+03 expected: -987.6E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.3) -9.877E+03 expected: -9.876E+03 (en15.1) -31.3E-03 expected:-31.2E-03 (en15.2) -15.63E-03 expected: -15.62E-03 (en15.3) -7.813E-03 expected: -7.812E-03 (en15.3)-976.563E-06 expected: -976.562E-06 This is with quad16.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #39 from Dominique d'Humieres --- > gfortran.dg/fmt_en.f90 tests fail on hppa*-*-hpux11* (4.8 and 4.9): > ... After r208780 (for 4.9, not backported yet to 4.8)?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #40 from dave.anglin at bell dot net --- On 25-Mar-14, at 11:14 AM, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 > > --- Comment #39 from Dominique d'Humieres ens.fr> --- >> gfortran.dg/fmt_en.f90 tests fail on hppa*-*-hpux11* (4.8 and 4.9): >> ... > > After r208780 (for 4.9, not backported yet to 4.8)? I'll know tomorrow whether update has helped. Dave -- John David Anglindave.ang...@bell.net
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #41 from dave.anglin at bell dot net --- On 25-Mar-14, at 11:14 AM, dominiq at lps dot ens.fr wrote: > After r208780 (for 4.9, not backported yet to 4.8)? Yes, it still fails on hppa2.0w-hp-hpux11.11. Maybe list is shorter: Unsupported rounding for real(16) (en15.0) 9.E+03 expected: 10.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 Dave -- John David Anglindave.ang...@bell.net
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #42 from Dominique d'Humieres ---
> > After r208780 (for 4.9, not backported yet to 4.8)?
>
> Yes, it still fails on hppa2.0w-hp-hpux11.11. Maybe list is shorter:
>
> Unsupported rounding for real(16)
> ...
So the line
! { dg-final { scan-file fmt_en.res "All kinds rounded to nearest" { xfail
i?86-*-solaris2.9* } } }
should be replaced with
! { dg-final { scan-file fmt_en.res "All kinds rounded to nearest" { xfail {
i?86-*-solaris2.9* hppa*-*-hpux11* } } } }
However I don't understand why you get the outputs, the corresponding tests are
supposed to be skipped if the rounding is not to nearest as detected.
Can you uncomment the line
!print *, n_tst, n_cnt
and post the corresponding output?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #43 from dave.anglin at bell dot net --- On 3/26/2014 8:51 AM, dominiq at lps dot ens.fr wrote: > Can you uncomment the line > > !print *, n_tst, n_cnt > > and post the corresponding output? (en15.2) -98.77E+03 expected: -98.76E+03 190 16
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #44 from Dominique d'Humieres --- What is the output of use ISO_FORTRAN_ENV print *, REAL_KINDS end ?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #45 from dave.anglin at bell dot net --- On 3/26/2014 11:09 AM, dominiq at lps dot ens.fr wrote: > What is the output of > >use ISO_FORTRAN_ENV >print *, REAL_KINDS > end > > ? 4 8 16
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #46 from Dominique d'Humieres ---
AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. What
is the output of the following test
#include "stdio.h"
int main() {
printf("%.1e %.1e\n", 9950.0, 9750.0);
return 0;
}
? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #47 from dave.anglin at bell dot net ---
On 3/26/2014 12:34 PM, dominiq at lps dot ens.fr wrote:
> AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. What
> is the output of the following test
>
> #include "stdio.h"
> int main() {
> printf("%.1e %.1e\n", 9950.0, 9750.0);
> return 0;
> }
>
> ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'.
You are correct:
9.9e+03 9.7e+03
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #48 from Dominique d'Humieres --- > > AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. > > What > > is the output of the following test > > > > ... > > > > ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'. > You are correct: > 9.9e+03 9.7e+03 OK! Unless someone beats me, I'll split the test in two, one for the main issue, the other one for the round to even on tie.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #49 from dave.anglin at bell dot net --- On 3/26/2014 2:07 PM, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 > > --- Comment #48 from Dominique d'Humieres --- >>> AFAICT on hppa*-*-hpux11* the E format does not round to nearest for tie. >>> What >>> is the output of the following test >>> >>> ... >>> >>> ? On x86_64-apple-darwin13, I get '1.0e+04 9.8e+03'. >> You are correct: >> 9.9e+03 9.7e+03 > OK! Unless someone beats me, I'll split the test in two, one for the main > issue, the other one for the round to even on tie. It looks like hppa rounds toward zero on tie. I couldn't find any documentation on the subject. For ia64, HP states that the rounding is according to C99.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #50 from dave.anglin at bell dot net --- On 3/26/2014 3:43 PM, dave.anglin at bell dot net wrote: > It looks like hppa rounds toward zero on tie. This is what the HP-UX Floating-Point Guide says: If two representable values are equally close to the true value, choose the one whose least significant bit is 0.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #51 from Dominique d'Humieres --- > This is what the HP-UX Floating-Point Guide says: > > If two representable values are equally close to > the true value, choose the one whose least significant > bit is 0. This is round to even on tie, isn't it?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #52 from dave.anglin at bell dot net --- On 3/26/2014 4:20 PM, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 > > --- Comment #51 from Dominique d'Humieres --- >> This is what the HP-UX Floating-Point Guide says: >> >> If two representable values are equally close to >> the true value, choose the one whose least significant >> bit is 0. > This is round to even on tie, isn't it? I'm not sure. The hex representations for 9900.0 (9.9e+3) and 1.0 (1.0e+4) are 40c35600 and 40c38800, respectively. It seems both have a zero least significant bit. So, something more is needed to break tie in this case. Dave
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #53 from Dominique d'Humieres ---
Dave, Rainer,
Could you test the following code?
[karma] f90/bug% cat fmt_en_1.f90
! { dg-do run }
! PR60128 Invalid outputs with EN descriptors
! Test case provided by Walt Brainerd.
program pr60128
use ISO_FORTRAN_ENV
implicit none
integer, parameter :: j(size(real_kinds)+4)=[REAL_KINDS, [4, 4, 4, 4]]
logical :: l_skip(4) = .false.
integer :: i
integer :: n_tst = 0, n_cnt = 0
character(len=20) :: s
open (unit = 10, file = 'fmt_en.res')
! Check that the default rounding mode is to nearest and to even on tie.
do i=1,size(real_kinds)
if (i == 1) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(1)), &
real(9750.0,kind=j(1))
else if (i == 2) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(2)), &
real(9750.0,kind=j(2))
else if (i == 3) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(3)), &
real(9750.0,kind=j(3))
else if (i == 4) then
write(s, '(2(1PE9.1))') real(9950.0,kind=j(4)), &
real(9750.0,kind=j(4))
end if
if (s /= ' 1.0E+04 9.8E+03') then
l_skip(i) = .true.
print "('Unsupported rounding for real(',i0,')')", j(i)
write (10, "('Unsupported rounding for real(',i0,')')") j(i)
end if
end do
call checkfmt("(en15.0)", 9500.0, "10.E+03")
call checkfmt("(en15.1)", 9950.0, " 10.0E+03")
call checkfmt("(en15.0)", -9500.0, " -10.E+03")
call checkfmt("(en15.1)", -9950.0, " -10.0E+03")
call checkfmt("(en15.1)", 987350., " 987.4E+03")
call checkfmt("(en15.2)", 98765., " 98.76E+03")
call checkfmt("(en15.1)", -987350., " -987.4E+03")
call checkfmt("(en15.2)", -98765., " -98.76E+03")
print *, n_tst, n_cnt
if (n_cnt /= 0) call abort
contains
subroutine checkfmt(fmt, x, cmp)
implicit none
integer :: i
character(len=*), intent(in) :: fmt
real, intent(in) :: x
character(len=*), intent(in) :: cmp
do i=1,size(real_kinds)
if (l_skip(i)) cycle
if (i == 1) then
write(s, fmt) real(x,kind=j(1))
else if (i == 2) then
write(s, fmt) real(x,kind=j(2))
else if (i == 3) then
write(s, fmt) real(x,kind=j(3))
else if (i == 4) then
write(s, fmt) real(x,kind=j(4))
end if
n_tst = n_tst + 1
if (s /= cmp) then
print "(a,1x,a,' expected: ',1x,a)", fmt, s, cmp
n_cnt = n_cnt + 1
end if
end do
end subroutine
end program
! { dg-final { scan-file-not fmt_en.res "Unsupported rounding" { xfail {
i?86-*-solaris2.9* hppa*-*-hpux11* } } } }
! { dg-final { cleanup-saved-temps } }
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #54 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #53 from Dominique d'Humieres ---
> Dave, Rainer,
>
> Could you test the following code?
Sure: passes on both i386-pc-solaris2.{9,10} with XFAILs on Solaris 9.
> ! { dg-final { scan-file-not fmt_en.res "Unsupported rounding" { xfail {
> i?86-*-solaris2.9* hppa*-*-hpux11* } } } }
> ! { dg-final { cleanup-saved-temps } }
Somehow long lines are broken if you put code inline. Perhaps better
attach it to the PR?
Thanks.
Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #55 from dave.anglin at bell dot net --- On 3/27/2014 11:00 AM, dominiq at lps dot ens.fr wrote: > Could you test the following code? Here is output: Unsupported rounding for real(4) Unsupported rounding for real(8) (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 8 2 Program aborted. Backtrace: ** Something went wrong while running addr2line. ** ** Falling back to a simpler backtrace scheme. ** #1 c033b5bf FAIL: gfortran.dg/fmt_en_1.f90 -O0 execution test XPASS: gfortran.dg/fmt_en_1.f90 -O0 scan-file-not Unsupported rounding So, probably abort shouldn't be called when rounding isn't supported. I would change "hpux11*" to "hpux*".
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #56 from Dominique d'Humieres --- > So, probably abort shouldn't be called when rounding isn't supported. The problem is that the rounding to even on tie seems supported by hpux, but for 98765.0_16 or -98765.0_16: 6 successes out of 8 tests. Could you post the output of print '(3PE10.3)', 987350._4 print '(3PE10.3)', 987350._8 print '(3PE10.3)', 987350._16 print '(2PE10.3)', 98765.0_4 print '(2PE10.3)', 98765.0_8 print '(2PE10.3)', 98765.0_16 end My problem is to know if this is coming from the default printing libs or from the EN format in libfortran. On *-*-darwin* I get 987.4E+03 987.4E+03 987.4E+03 98.76E+03 98.76E+03 98.76E+03
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #57 from Jerry DeLisle --- Your results on Darwin match gfortran and ifort on x86-64.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #58 from dave.anglin at bell dot net --- On 27-Mar-14, at 6:31 PM, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 > > --- Comment #56 from Dominique d'Humieres ens.fr> --- >> So, probably abort shouldn't be called when rounding isn't supported. > > The problem is that the rounding to even on tie seems supported by > hpux, but > for > 98765.0_16 or -98765.0_16: 6 successes out of 8 tests. Could you > post the > output of > > print '(3PE10.3)', 987350._4 > print '(3PE10.3)', 987350._8 > print '(3PE10.3)', 987350._16 > print '(2PE10.3)', 98765.0_4 > print '(2PE10.3)', 98765.0_8 > print '(2PE10.3)', 98765.0_16 > end > > My problem is to know if this is coming from the default printing > libs or from > the EN format in libfortran. > > On *-*-darwin* I get > > 987.4E+03 > 987.4E+03 > 987.4E+03 > 98.76E+03 > 98.76E+03 > 98.76E+03 Results are on hppa2.0w-hp-hpux11.11: 987.3E+03 987.3E+03 987.4E+03 98.77E+03 98.77E+03 98.77E+03 -- John David Anglindave.ang...@bell.net
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #59 from Dominique d'Humieres --- Created attachment 32485 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32485&action=edit Patch for gfortran.dg/fmt_en.f90 Could you test the attached patch?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #60 from dave.anglin at bell dot net --- On 29-Mar-14, at 12:12 PM, dominiq at lps dot ens.fr wrote: > Could you test the attached patch? Test no longer fails on hppa2.0w-hp-hpux11.11: Unsupported rounding for real(4) Unsupported rounding for real(8) Unsupported rounding for real(16) 0 0 0 PASS: gfortran.dg/fmt_en.f90 -O0 execution test XFAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest -- John David Anglindave.ang...@bell.net
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #61 from Dominique d'Humieres --- > Test no longer fails on hppa2.0w-hp-hpux11.11: > > Unsupported rounding for real(4) > Unsupported rounding for real(8) > Unsupported rounding for real(16) >0 0 0 > PASS: gfortran.dg/fmt_en.f90 -O0 execution test > XFAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest Actually all the tests are skipped. I have forgotten to remove the line if (l_skip(i)) cycle Could you rerun the test without this line? You should get something such as 285 0 30 Sorry for the mistake!-(
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #62 from dave.anglin at bell dot net --- On 29-Mar-14, at 7:30 PM, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 > > --- Comment #61 from Dominique d'Humieres ens.fr> --- >> Test no longer fails on hppa2.0w-hp-hpux11.11: >> >> Unsupported rounding for real(4) >> Unsupported rounding for real(8) >> Unsupported rounding for real(16) >> 0 0 0 >> PASS: gfortran.dg/fmt_en.f90 -O0 execution test >> XFAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to >> nearest > > Actually all the tests are skipped. I have forgotten to remove the > line > > if (l_skip(i)) cycle > > Could you rerun the test without this line? You should get something > such as > > 285 0 30 Yes: Unsupported rounding for real(4) Unsupported rounding for real(8) Unsupported rounding for real(16) 285 0 30 -- John David Anglindave.ang...@bell.net
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE --- On i386-pc-solaris2.9, I get the same PASSes and XFAILs as before: Unsupported rounding for real(16) 380 0 52 PASS: gfortran.dg/fmt_en.f90 -Os execution test XFAIL: gfortran.dg/fmt_en.f90 -Os scan-file All kinds rounded to nearest Rainer
