[Bug other/48111] libquadmath: strtoflt128 bug on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48111 Thomas Henlich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Thomas Henlich --- Cannot reproduce failure in tests 3 and 7 with gcc version 7.0.0 20161204 (experimental) (GCC) Closing.
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net --- (In reply to Jerry DeLisle from comment #10) gfortran currently does this with default formatting, list directed outout: - ( 1., 0.) ( -1.0002E-25, 0.) ( -1.0002E-25, 0.) ( 1., 0.) ( -3.4992E-24, -3.4992E-24) ( -4.1998E-24, -1.2703E-23) ( 1., 0.) ( -1.0002E-25, 0.) - I have my experimental doing this: case A - (1.,0.) (-0.1000E-24,0.) (-0.1000E-24,0.)(1.,0.) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0.) (-0.1000E-24,0.) - I could also do this: case B - (1.,0. ) (-0.1000E-24,0. ) (-0.1000E-24,0. ) (1.,0. ) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0. ) (-0.1000E-24,0. ) - or is there some other arrangement? I think your case B is invalid, because no spaces are allowed in constants, i.e. between the parentheses (see above). There is also case C (right-flush in 2*w+3): - (1.,0.) (-0.1000E-24,0.) (-0.1000E-24,0.) (1.,0.) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0.) (-0.1000E-24,0.) - The standard says: Numeric editing, General rules: ... On output, the representation is right justified in the field. If the number of characters produced by the editing is smaller than the field width, leading blanks are inserted in the field.
[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659 --- Comment #7 from Thomas Henlich thenlich at users dot sourceforge.net 2011-09-05 07:55:13 UTC --- Would it be feasible to generate a warning for line 3 of the following: real(8) :: a, b a = 1.4d0 b = a / 1.3
[Bug libfortran/50105] Possibly: [4.3/4.4/4.5/4.6/4.7 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 --- Comment #3 from Thomas Henlich thenlich at users dot sourceforge.net 2011-08-17 07:36:54 UTC --- Maybe we can trace back the change in GFortran between 4.1 and 4.3 and find out why it was changed?
[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659 --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-08-08 06:07:33 UTC --- It is not safe to omit the warning for integers: the constant could have been truncated to an integer, as in: real(8) :: r8 r8 = 12345678.9 print *, r8 = 12345679.000 So the best we can do is probably the unconditional warning. Maybe the warning in this case should only be emitted when -Wconversion-extra is in effect. That's how it works for variables (conversion to a higher precision), it should be the same for constants (for consistency). Similarly, for -Wconversion-extra the conversion to a lower precision should always give a warning, even if no digits are lost.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #38 from Thomas Henlich thenlich at users dot sourceforge.net 2011-07-01 09:22:48 UTC --- The Fortran standards committee has voted to edit the standard: http://j3-fortran.org/doc/meeting/195/11-174r2.txt This makes our current approach standard compliant (with the corrigendum to be published) This also means an additional todo item for this bug is If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee editing respectively.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added CC||thenlich at users dot ||sourceforge.net --- Comment #7 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-30 12:26:30 UTC --- J3 subgroup has answered this: http://j3-fortran.org/doc/meeting/195/11-201r1.txt
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #26 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-23 06:13:12 UTC --- Created attachment 24583 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24583 More tests for rounding If it helps, I added some more tests for this. By removing the code lines in questions, all tests from this testcase pass except: call checkfmt((RU,F2.0), 0.09, 1.) ! 0. call checkfmt((RD,F3.0), -0.09, -1.) ! -0.
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #24 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-20 07:15:19 UTC --- (In reply to comment #22) This is kind of bad: print (RU,F7.0), 7500.0 ! 8. expected 7500. print (RD,F7.0), -7500.0 ! -8. expected -7500. I've traced the bug down to this code: http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/write_float.def?r1=173231r2=173408pathrev=173408 + rchar = '0'; + if (w 0 d == 0 p == 0) +nbefore = 1; + /* Scan for trailing zeros to see if we really need to round it. */ which I don't understand. Why are we setting the number of digits before the decimal point to 1 if the width is zero and the scale factor is zero and the number of requested digits after the decimal point is zero?
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #22 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-17 13:22:42 UTC --- This is kind of bad: print (RU,F7.0), 7500.0 ! 8. expected 7500. print (RD,F7.0), -7500.0 ! -8. expected -7500.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #35 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-10 16:56:02 UTC --- (In reply to comment #33) The last test case I am working is fmt_g0_6.f08. The apparent failing case is: print (rc,g15.2), 0.995000_8 Which is resulting in 0.99 and we expect it to be 1.0. However, the raw internal representation of 0.995 is not exact and is: 99499555 This places the value less then the threshold given in the table in the Standard, giving the correct F format as: print (f11.2,4x), 0.995000_8 ! 0.99 Instead of print (f11.1,4x), 0.995000_8 ! 1.0 Our F formatting in the test case is using the f11.1 and the logic does not look at the third digit and dutifully rounds the value as it should. The new G formatting is using exact integer logic and dutifully does look at the third digit. If we do: print (rc,g15.2), 0.9950001_8 The internal value does cross the 0.995 threshold and we do get the 1.0 results. I think this issues is one of those splitting hairs things. We could artificially round the digits string early before we process it, but this would effectively be rounding twice to get there. I would prefer to revise the test case like so: call check_all(0.9951_RT, 15, 2, 0) and be done with this. The result is correct, but our expectation was wrong. 0.995000_8 which is internally 0.99499555... is smaller than 0.995 (exact value) so it must output 0.99, not 1.0. Please don't waste time with this test case (fmt_g0_6.f08), it is broken. I will fix this some time.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #36 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-10 17:01:34 UTC --- (In reply to comment #34) Additional note: The standard states: Let N be the magnitude of the internal value The internal value is to be used to determine the conversion to F formatting. I think this adds to my point. I wonder if the standards committee knew the thresholds selected do not have an exact binary representation so that the internal values will always be above or below it. Not always (e.g. 99.5 is the exact internal value), but it many cases, yes. This and other problems with G editing will be fixed in the standard soon, if all goes well. I helped to prepare a request for this, which has now been submitted: http://j3-fortran.org/doc/year/2011/11-174.txt
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #30 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-07 06:56:13 UTC --- Created attachment 24454 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24454 Patch for scale factor. PUBLIC DOMAIN
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #31 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-07 06:56:54 UTC --- (In reply to comment #30) Created attachment 24454 [details] Patch for scale factor. PUBLIC DOMAIN A had a go at this. Feel free to improve.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #24 from Thomas Henlich thenlich at users dot sourceforge.net
2011-06-06 08:38:13 UTC ---
(In reply to comment #23)
Patch submitted to list for approval.
For a scale factor 0, we are done. Good work, thank you!
A scale factor != 0 does not work yet, you wrote you are still working on it,
is that correct?
print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01
print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00
print (0pg12.3), 0.02 ! 0.200E-01
print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02
print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03
--- gcc/testsuite/gfortran.dg/pr20755.f(revision 174320)
+++ gcc/testsuite/gfortran.dg/pr20755.f(working copy)
@@ -5,8 +5,8 @@
character*30 s
write (s,2000) 0.0, 0.02
- if (s .ne. 0.00 2.000E-02) call abort
+ if (s .ne. 0.00 0.200E-01) call abort
write (s,2000) 0.01, 0.02
- if (s .ne.1.000E-02 2.000E-02) call abort
+ if (s .ne.0.100E-01 0.200E-01) call abort
2000 format (1PG12.3,G12.3)
end
I don't agree with the changes to this testcase, since the scale factor does
not work yet, and the test was correct before.
--- gcc/testsuite/gfortran.dg/fmt_g0_6.f08(revision 174320)
+++ gcc/testsuite/gfortran.dg/fmt_g0_6.f08(working copy)
@@ -57,7 +57,7 @@ contains
do dec = d, 0, -1
lower = 10.0_RT ** (d - 1 - dec) - r * 10.0_RT ** (- dec - 1)
upper = 10.0_RT ** (d - dec) - r * 10.0_RT ** (- dec)
-if (lower = mag .and. mag upper) then
+if (lower mag .and. mag = upper) then
write(fmt_f, ('R', a, ',F', i0, '.', i0, ',', i0, 'X'))
roundmode, w - n, dec, n
exit
end if
I don't agree with this change, since it was according to the Fortran standard
before (it does not actually make a difference for the values we currently
check in this test, though.)
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #26 from Thomas Henlich thenlich at users dot sourceforge.net
2011-06-06 12:27:38 UTC ---
(In reply to comment #25)
My confusion seems to be when scale factor is to be ignored and when not, I
will give the standard another read.
As it happens, you're not the only one to find (this part of) the Fortran
standard confusing and buggy, so if all goes as planned there will be a
rewrite:
-
11-xxx
To: J3
From: John Reid and Thomas Henlich
Subject: Interp: G editing for reals
Date: 2011 June 5
-
NUMBER: F08/
TITLE: G editing for reals
KEYWORDS: format, G editing
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress
QUESTION:
1. Gw.d editing for a real value that is in the range (0.1,10**d) and
is not near an integer power of 10 uses F editing to produce exactly
the same value as 0PEw.d editing would produce. For values in this
range that are near an integer power of 10, is it intended that F
editing be used to produce exactly the same value as 0PEw.d editing
would produce?
The rules in 10.7.5.2.2 usually have this effect, but the following
examples illustrate exceptions for rounding UP and to ZERO.
i.
print (ru,g11.2), -9.95
or
print (rz,g11.2), -9.95
Here, 0PE11.2 editing would produce the value -0.99E+01, which can be
represented as -9.9. However, the standard requires F7.0 to be used,
which gives the result -9. Note that the standard requires
print (rd,g11.2), 9.95
and
print (rz,g11.2), 9.95
to give the result 9.9.
ii.
print (ru,0p,g11.2), -99.5
The standard requires 0PE11.2 editing to be used, which gives
-0.99E+02. This is representable as -99.
iii.
print (ru,0p,g11.2), 99.
The standard requires 0PE11.2 editing to be used, which gives
0.99E+02. This is representable as 99.
2. COMPATIBLE and NEAREST modes of rounding differ only when the two
nearest representable values are equidistant from the given value. The
similarity appears not to be represented in the second table. What is
meant by if the higher value is even?
3. Why is no account taken of the effects when PROCESSOR_DEFINED
rounding is in effect?
ANSWER:
1. Yes, this was the intention and it would be clearer for the standard
to state this directly. It would also be easier for implementers to
implement.
2. If the standard is rewritten as proposed in the first question, these
further problems would be resolved.
3. If the standard is rewritten as proposed in the first question,
PROCESSOR_DEFINED rounding would be covered.
EDITS to 10-007r1:
[258:14-20] In 10.7.5.2.2, replace paragraph 4 by
Otherwise, the method of representation in the output field depends
on the internal value being edited. Let N be the value that would be
output with 0PEw.dEe editing and let s be its exponent part unless N
is identically 0 in which case let s be 1. Let k be the scale factor
(10.8.5). Let b be a blank. For Gw.d editing, if s lies in the range
0 = s = d, F(w-4).(d-s),4('b') editing is used to represent N in the
output field; otherwise, kPEw.d editing is used to represent the
internal value. For Gw.dEe editing, if s lies in the range 0 = s = d,
F(w-n).(d-s),n('b') editing where n=e+2 is used to represent N in the
output field; otherwise, kPEw.dEe editing is used to represent the
internal value.
SUBMITTED BY: John Reid and Thomas Henlich
HISTORY: 11-xxxm195 Submitted
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #28 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-06 12:41:55 UTC --- I had a look at the code and what I think we should do is the following: If G editing and a scale factor p != 0 is in effect, split the rounding step into 2 steps: First, check if overflow occurs (... = 1....) but do not actually overwrite the digits yet. With this information, we determine the final value of e. If it turns out we need F editing: Repeat the rounding as above (or remember if overflow occured the first time), and this time actually overwrite the digits. If it turns out we need E editing: Set the new value for the number of digits according to p and repeat the rounding. It may help to refactor some of the code into a separate function, since we need to call it twice.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #29 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-06 12:47:58 UTC --- (In reply to comment #27) print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01 print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00 print (0pg12.3), 0.02 ! 0.200E-01 print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02Too many significant digits? print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03 Too many significant digits? Should these last two cases by 2.00E-02 and 20.0E-03 ? Otherwise we seem to be adding an extra significant digit. Help me understand this. Don't worry, it's not your fault... Say goodbye to the world of common sense, welcome to the world of the Fortran standard! ;-) The scale factor k controls the decimal normalization (10.3.2, 10.8.5). If −d k = 0, the output field contains exactly |k| leading zeros and d − |k| significant digits after the decimal symbol. If 0 k d + 2, the output field contains exactly k significant digits to the left of the decimal symbol and d − k + 1 significant digits to the right of the decimal symbol. Other values of k are not permitted.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #19 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-01 06:26:27 UTC --- Also, the test case, pr20755.f was originally intended to pass only with -std=legacy. This is to mimic g77 which does not ignore the scale factor. At least recently, gfortran passes this test case regardless of the -std=. I am tempted to delete the test case, since it looks like it goes against current standards. Any opinions about this? Now you've lost me. From what I understand PR20755 was about G editing resetting the scale factor in certain cases (to 0 in the example) and not restoring it afterwards (to 1 in this case). This is a bug both in legacy and in Fortran standard modes. The bug was fixed and a testcase was created. The result is standard-compliant. Why would you want to remove the testcase? The point of having a testcase is to prevent a reappearing of the same bug in the future, so maybe we should keep it.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #20 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-01 08:12:31 UTC --- (In reply to comment #18) Created attachment 24406 [details] New updated patch This updated patch takes care of Comment #16. Unfortunately, now the other testcases fail again (although with still another results): print (ru,g15.2), .099d0 ! 0.10E-01 expected 0.10 print (rc,g15.1), .095d0 ! 0.1E-01 expected 0.1 print (rc,g15.2), .0995d0 ! 0.10E-01 expected 0.10 print (ru,g15.3), .0999d0 ! 0.100E-01 expected 0.100 print (rc,g10.2), 99.5 ! 0.10E+02 expected 0.10E+03 print (rc,g10.2), 995. ! 0.10E+03 expected 0.10E+04 print (rc,g10.3), 999.5 ! 0.100E+03 expected 0.100E+04 print (rc,g10.3), 9995. ! 0.100E+04 expected 0.100E+05 It seems there is still a bug that doesn't increment the exponent in the overflow case, i.e. when going from 0....E(x) to 0.1000...E(x+1) The exponent test (decision between F and E editing) must be done after that! I can not find this in the code right now.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #15 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-31 06:05:19 UTC --- I hadn't really thought of that, but now I see what a PITA a scale factor 0 is going to be (scale factor 0 is simply padding with zeros and shifting digits): We have to ignore the scale factor, until we decide that we use E editing, at which point we need an additional digit in the result. For efficiency: Maybe we can decide that we use E editing without actually overwriting the original digits at that point yet, so we can go back when we actually switch to E editing and re-do the rounding with the extra digit.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #16 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-31 06:28:25 UTC --- print (rc,g11.1), 2. ! 0.2E+01 expected 2. print (rc,g11.2), 20. ! 0.20E+02 expected 20. print (rc,g11.3), 200. ! 0.200E+03 expected 200. print (rc,g11.4), 2000. ! 0.2000E+04 expected 2000. print (rc,g11.2), .04 ! 0.40 expected 0.40E-01 print (rc,g11.3), .04 ! 0.400 expected 0.400E-01
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #10 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 07:15:16 UTC --- The test cases from above still fail (but with a different result): print (ru,g15.2), .099d0 ! 1.0E-01 expected 0.10 print (rc,g15.1), .095d0 ! 1.E-01 expected 0.1 print (rc,g15.2), .0995d0 ! 1.0E-01 expected 0.10 print (ru,g15.3), .0999d0 ! 1.00E-01 expected 0.100 Also, G0.d tests fail in the E formatting case, the chosen format is E25.(d)E3 and not the minimal width required for G0.d: print (rc,g0.4,''), .1234d-3 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d-2 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d-1 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d0 print (rc,g0.4,''), .1234d1 print (rc,g0.4,''), .1234d2 print (rc,g0.4,''), .1234d3 print (rc,g0.4,''), .1234d4 print (rc,g0.4,''), .1234d5 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d6 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d7 ! fixed width, not G0.d format
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 08:55:14 UTC --- The scale factor is applied to F editing, but it shouldn't. See Fortran 2008: NOTE 10.20 The scale factor has no effect on output unless the magnitude of the datum to be edited is outside the range that permits effective use of F editing. print (rc,1p,g15.4e2,''), 0.1234 ! 1.2340E-01 expected 0.1234 print (rc,g15.4e2,''), 0.1234 ! 0.1234 Additionally, there is a strange digit mixup in this case: print (rc,-1p,g15.4e2,''), 0.1234 ! 1.0234 expected 0.1234
[Bug libfortran/49188] New: Mismatch between -fsign-zero documentation and formatted output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188 Summary: Mismatch between -fsign-zero documentation and formatted output Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The documentation of the -fsign-zero option mentions floating point numbers of value zero with the sign bit set: When enabled, floating point numbers of value zero with the sign bit set are written as negative number in formatted output and treated as negative in the SIGN intrinsic. fno-sign-zero does not print the negative sign of zero values and regards zero as positive number in the SIGN intrinsic for compatibility with F77. Default behavior is to show the negative sign. However the flag also affects the output of numbers with a value other than zero, which have their non-zero digits truncated due to formatting. E.g.: print (rc,f4.1), -0.04 -fsign-zero: -0.0 -fno-sign-zero: 0.0 This fno-sign-zero behaviour is not according to the Fortran standard (a minus sign if the internal value is negative) including F77 which is explicitly mentioned in the documentation. (Or is this referring to a specific, possibly non-Fortran77-compliant compiler named F77?) The only sense this would make is if this option would be restricted to actually do what it says in the documentation, regarding a zero with the sign bit set as a mathematical zero, a non-negative value. In my opinion the formatting routines for real numbers should be changed to only affect zero values. Additionally, the last sentence (Default behavior is to show the negative sign.) should be made more precise (e.g. The option is enabled by default) to reflect that the SIGN intrinsic is also affected by the default setting.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 13:12:32 UTC --- The following examples fail: print (rc,g10.2,''), 99.5 ! 10. expected 0.10E+03 print (rc,g10.2,''), 995. ! 1.0E+03 expected 0.10E+04 print (rc,g10.3,''), 999.5 ! 100. expected 0.100E+04 print (rc,g10.3,''), 9995. ! 1.0E+04. expected 0.100E+05
[Bug libfortran/49188] Mismatch between -fsign-zero documentation and formatted output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Severity|normal |minor --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 18:41:38 UTC --- In this case a more precise documentation should be something like: When enabled, floating point numbers with the sign bit set are always written with a negative sign even if the formatted output contains no other digits than zero. In addition, floating point numbers of value zero with the sign bit set are treated as negative in the SIGN intrinsic. fno-sign-zero does not print the negative sign of such values and regards zero as positive number in the SIGN intrinsic for compatibility with g77. fsign-zero is the default.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-19 08:05:32 UTC --- (In reply to comment #5) As a general rule, d specifies the number of significant digits in the result, i.e. the number of digits counting from the first non-zero digit. So in the example all numbers should be formatted with 2 significant digits, i.e. 2 decimal digits if the value rounded to 2 significant digits is smaller than 1, and 1 decimal digit if the value rounded to 2 significant digits is larger than or equal to 1. implicit none integer, parameter :: RT = 8 write(*, (rc,f11.2,4x,'RC')) .995_RT write(*, (rc,g15.2,'RC')) .995_RT write(*, (rd,f11.2,4x,'RD')) .995_RT write(*, (rd,g15.2,'RD')) .995_RT write(*, (ru,f11.2,4x,'RU')) .995_RT write(*, (ru,g15.2,'RU')) .995_RT write(*,'(a)') 12345678901234567890 end 0.99RC 0.99RC 0.99RD 0.99RD 1.00RU 1.0RU 12345678901234567890 and write(*, (ru,f11.1,4x,'RU')) .995_RT gets 1.0RU
[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 --- Comment #5 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-17 05:51:56 UTC --- The fmod behaviour is correct for x 0 according to N1548: double fmod(double x, double y); float fmodf(float x, float y); The fmod functions return the value x−ny, for some integer n such that, if y is nonzero, the result has the same sign as x and magnitude less than the magnitude of y. If y is zero, whether a domain error occurs or the fmod functions return zero is implementation-defined.
[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 --- Comment #7 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-17 11:57:31 UTC --- I suppose we could still use __builtin_fmod if we reset the sign bit if the result is -0.
[Bug libfortran/49024] New: REAL*16 ERFC_SCALED inaccuracy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49024 Summary: REAL*16 ERFC_SCALED inaccuracy Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The libfortran implementation of the ERFC_SCALED intrinsic function is not accurate enough to be useful for REAL*16 arithmetics. program test_erfc_scaled real(16), parameter :: p16 = 1.0_16 real(16) :: v16 = p16 print *, erfc_scaled(v16) print *, erfc_scaled(p16) print *, erfc(v16) * exp(v16 * v16) end program test_erfc_scaled == 0.427583576155807003967191251980322016 0.427583576155807004410750344490515188 0.427583576155807004410750344490515140 This should be easy to fix by adding an erfc_scaled() function to libquadmath. In fact, the error function code in libquadmath is based on the same code as http://www.netlib.org/cephes/128bdoc.html and the latter already contains a separate function for a scaled error function. In libquadmath it has been merged into one (or maybe the other was split later).
[Bug fortran/49010] New: Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 Summary: Result of MOD and MODULO intrinsic has wrong sign Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net If the first argument to the MOD and MODULO intrinsic is negative, and the magnitude of the result is zero, the function returns a negative zero. Fortran 2003/2008: MOD: The value of the result is A − INT (A/P) * P. MODULO: The value of the result is A − FLOOR (A / P) * P. The values returned by these intrinsics should be the same as the expressions by which the functions are defined; which is zero, without a negative sign. Example: program test_mod real :: a, p a = -4.0 p = 2.0 print *, mod(a, p), a - int(a / p) * p ! -0 0 expected 0 0 print *, modulo(a, p), a - floor(a / p) * p ! -0 0 expected 0 0 end program test_mod
[Bug fortran/49011] New: Wrong repeat count in error message for REPEAT intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011 Summary: Wrong repeat count in error message for REPEAT intrinsic Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net If the REPEAT intrinsic is given a negative NCOPIES argument at runtime, in the resulting error message an erraneous value is printed. Example: program test_repeat integer :: i = -1 print *, repeat(x, i) end program test_repeat $ ./a.out At line 3 of file test_repeat.f90 Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its value is 4294967295) Expected result: At line 3 of file test_repeat.f90 Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its value is -1)
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-15 09:13:28 UTC --- (In reply to comment #9) Thus, I do not see how one can solve this better than currently done. We might call system() in a separate thread instead of a separate process which is more efficient and would also work on Windows.
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-15 09:26:02 UTC --- (In reply to comment #11) (In reply to comment #9) Thus, I do not see how one can solve this better than currently done. We might call system() in a separate thread instead of a separate process which is more efficient and would also work on Windows. The drawback is that the calling application would not exit before system() has returned or possibly would abort the running command. So it seems the current implementation is not so bad after all.
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-14 12:54:26 UTC --- Maybe I'm wrong, but I'm not sure the current implementation of asynchronous execution is very efficient (on Unix systems): We fork() and then call system(), which forks again and runs a shell, then the shell exits, the forked process inside system() exits, the we exit our forked process. I think we might as well just fork and exec the shell directly which would save one process creation. We also don't need the exit value from the system() call in Fortran.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-13 09:13:01 UTC --- Mind the change between F2003 and F2008: F2003: FRACTION(+Inf) = +Inf FRACTION(-Inf) = -Inf F2008: FRACTION(+Inf) = NaN FRACTION(-Inf) = NaN And I think what If X is an IEEE NaN, the result is that NaN. means is: IF ISNAN(X) FRACTION(X) = X which is different from IF ISNAN(X) FRACTION(X) = Z'7FC0'
[Bug fortran/45823] Bogus warning for intrinsic module procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45823 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added CC||thenlich at users dot ||sourceforge.net --- Comment #1 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 09:40:37 UTC --- Here is another example. The warning appears even if there are no calls to to compiler_options() or compiler_version(). This bug basically makes the option -Wsurprising useless in combination with iso_fortran_env. test_mod.f90: module test_mod use iso_fortran_env end module test_mod test.f90: use test_mod end gcc -c test_mod.f90 gfortran -c -Wsurprising test.f90 test.f90:1.12: use test_mod 1 Warning: Type specified for intrinsic function 'compiler_options' at (1) is ignored test.f90:1.12: use test_mod 1 Warning: Type specified for intrinsic function 'compiler_version' at (1) is ignored
[Bug fortran/48979] New: FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Summary: FRACTION und EXPONENT return invalid results for infinity/NaN Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net program test_fractnan real, parameter :: pinfp = transfer(z'7F80', 0.0) real, parameter :: ninfp = transfer(z'FF80', 0.0) real, parameter :: nanp = transfer(z'7FD0', 0.0) real, parameter :: zerop = 0.0 real :: nan = nanp, pinf = pinfp, ninf = ninfp, zero = zerop print 100, zero, zero, fraction(zero), fraction(zero), exponent(zero) print 100, zerop, zerop, fraction(zerop), fraction(zerop), exponent(zerop) print 100, nan, nan, fraction(nan), fraction(nan), exponent(nan) print 100, nanp, nanp, fraction(nanp), fraction(nanp), exponent(nanp) print 100, ninf, ninf, fraction(ninf), fraction(ninf), exponent(ninf) print 100, ninfp, ninfp, fraction(ninfp), fraction(ninfp), exponent(ninfp) print 100, pinf, pinf, fraction(pinf), fraction(pinf), exponent(pinf) print 100, pinfp, pinfp, fraction(pinfp), fraction(pinfp), exponent(pinfp) 100 format (f10.5,1x,z8,1x,f10.5,1x,z8,1x,i11) end program test_fractnan Result: 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 0 NaN 7FD00.00 0 -Infinity FF80 -Infinity FF80 0 -Infinity FF80NaN 7FC0 -2147483645 Infinity 7F80 Infinity 7F80 0 Infinity 7F80NaN 7FC0 -2147483645 Expected result (-std=f2003): 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 2147483647 NaN 7FD0NaN 7FD0 2147483647 -Infinity FF80 -Infinity FF80 2147483647 -Infinity FF80 -Infinity FF80 2147483647 Infinity 7F80 Infinity 7F80 2147483647 Infinity 7F80 Infinity 7F80 2147483647 Expected result (-std=f2008): 0.000.00 0 0.000.00 0 NaN 7FD0NaN 7FD0 2147483647 NaN 7FD0NaN 7FD0 2147483647 -Infinity FF80NaN 7FC0 2147483647 -Infinity FF80NaN 7FC0 2147483647 Infinity 7F80NaN 7FC0 2147483647 Infinity 7F80NaN 7FC0 2147483647 EXPONENT(X) Fortran 2003/2008: If X is an IEEE infinity or NaN, the result has the value HUGE (0). FRACTION(X) Fortran 2003: If X is an IEEE infinity, the result is that infinity. If X is an IEEE NaN, the result is that NaN. Fortran 2008: If X is an IEEE NaN, the result is that NaN. If X is an IEEE infinity, the result is an IEEE NaN. Bug 1: The program does not compile without -fno-range-check. Bug 2: Different results are returned for a variables with values of NaN/Infinity and compile-time constants NaN/Infinity. Bug 3: EXPONENT should be HUGE(0)=2147483647 for NaN/Infinity.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 17:34:27 UTC --- (In reply to comment #1) (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug? I consider it a bug because the result of the expressions FRACTION(Infinity) and FRACTION(NaN) is defined by the Fortran standard, so the compiler should not throw an error on simplifying them. Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do).
[Bug libfortran/48958] New: Add runtime diagnostics for SIZE intrinsic function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958 Summary: Add runtime diagnostics for SIZE intrinsic function Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net As has been brought up before (Bug 20406), the SIZE intrinsic returns an unpredictable result if the argument is an unallocated allocatable or a pointer that is not associated. While this is perfectly standard-conforming behaviour, it would be helpful in program development to have SIZE throw a runtime error if this condition occurs. I.e. SIZE should first check if an array is ALLOCATED or a pointer is ASSOCIATED and abort with a runtime error if that is not the case. Fortran 2008: 13.7.156 SIZE (ARRAY [, DIM, KIND]) 3 Arguments. ARRAY shall be an array of any type. It shall not be an unallocated allocatable variable or a pointer that is not associated. If ARRAY is an assumed-size array, DIM shall be present with a value less than the rank of ARRAY.
[Bug libfortran/48960] New: OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 Summary: OPEN statement modifies NEWUNIT variable on error Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net If the NEWUNIT= specifier in the OPEN statement is used, the variable is modified if an error occurs during the execution of the OPEN statement. This does not conform to Fortran 2008 which demands: 9.5.6.12 NEWUNIT= specifier in the OPEN statement 1 The variable is defined with a processor determined NEWUNIT value if no error occurs during the execution of the OPEN statement. If an error occurs, the processor shall not change the value of the variable. Example: program test_newunit integer :: st, un = 0 open (newunit=un, file='nonexisting.dat', status='old', iostat=st) if (un /= 0) call abort end program test_newunit Result: If the file 'nonexisting.dat' does not exist, the program aborts. Expected result: If the file 'nonexisting.dat' does not exist, the program should not abort.
[Bug libfortran/48961] New: EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 Summary: EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net When calling the EXECUTE_COMMAND_LINE intrinsic on Windows and setting the WAIT argument to .false., the execution causes a runtime error. For example: program hello print *, Hello world end program hello program test_execute call execute_command_line(hello.exe, .false.) end program test_execute test_execute Hello world Fortran runtime error: Could not execute command line Expected result: No runtime error should occur. Fortran 2008: 13.7.57 EXECUTE_COMMAND_LINE (COMMAND [, WAIT, EXITSTAT, CMDSTAT, CMDMSG ]) ... 3 Arguments. ... WAIT (optional) shall be a default logical scalar. It is an INTENT (IN) argument. If WAIT is present with the value false, and the processor supports asynchronous execution of the command, the command is executed asynchronously; otherwise it is executed synchronously. 5 When the command is executed synchronously, EXECUTE_COMMAND_LINE returns after the command line has completed execution. Otherwise, EXECUTE_COMMAND_LINE returns without waiting.
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-11 16:38:52 UTC --- The program is executed, as the called program hello.exe prints Hello world. After that hello.exe returns and the runtime error occurs. Further testing shows that it is executed synchronously, presumably because asynchronous execution is not implemented (yet?) on Windows.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-10 17:16:47 UTC --- Way to go! I'll be happy to test.
[Bug libfortran/48925] New: Code cleanup in write_float.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925 Summary: Code cleanup in write_float.def Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net For improvement in code quality and possible future modifications, I suggest to separate the steps digit generation and number formatting into separate functions. 1. There should be a function Digit generation. Input: - a floting-point number (e.g. -.123456789E+12) - the rounding mode (up/down etc.) - mode: fixed-point (F editing), or floating-point (E/ES/G), or engineering (EN) - number of significant digits (floating-point), number of decimal digits (F) Output: - a string with the digits of the rounded significand (e.g. 123457) - an integer exponent (e.g. 12), or position of the decimal separator - the sign flag (- or +) 2. There should be a function number formatting Input: - s.a. Output - the edit descriptor (F/E/G...) - Field width w and number of requested digits d Output: - A buffer with the formatted number (e.g.+1.23457E+011) Function 2 is independent of the floating-point precision, so we don't need it four times for all the different real kinds, only one time.
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-05 06:50:13 UTC --- (In reply to comment #3) neither 0PFw.d nor 1PEw.dEe allow it). However, AFAICS leading blanks are still allowed as they are part of the real parts, the prohibition against embedded blanks in the complex output refer only to blanks other than the ones present in the real fields, no? As much as I'd like to, I cannot agree: The only embedded blanks permitted within a complex constant are between the separator and the end of a record and one blank at the beginning of the next record. An embedded blank within a complex constant is any blank which neither leads the complex constant nor trails it; in other words, any space between the left and the right parenthesis. It is not permitted, except around record breaks. If it is important, we can still ensure the tabular alignment of complex fields by right-flushing them in a field of width 2*w+3, where w is the width for a real constant.
[Bug libfortran/48511] Implement Steele-White algorithm for numeric output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511 --- Comment #13 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-05 10:57:33 UTC --- G95 is actually using this method for list-directed output. print *, .3, .33, .333, ., .3, .33, .333 g95 = 0.3 0.33 0.333 0. 0.3 0.33 0.333 gfortran = 0.30012 0.33013 0.33304 0.33324 0.30005 0.32986 0.33313 From ftoa.c: /* All software © 1996 Robert G. Burger. Permission is hereby granted, ... * This code is described in an article by Robert G. Burger and * R. Kent Dybvig in Proceedings of the ACM SIGPLAN '96 Conference on * Programming Language Design and Implementation, pages 108-116, May * 1996. * * Modified for use with g95 by Andy Vaught. Thanks Bob! */
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-05 13:31:47 UTC --- (In reply to comment #6) Also, See below. Does this give the expected output? print *, (1.0, 0.0) end $ ./a.out (1.,.) I personally prefer the optional zero before the decimal separator to be printed, because we have done so and still do for real numbers: (1.,0.)
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #49 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-04 12:48:28 UTC --- (In reply to comment #47) (In reply to comment #46) I have started on the second phase of this effort which is to get rid of the floating point issue on -m32 machines. Hello. I have noticed a bug which seems related to the one you are describing. According to the Fortran 95 standard, printing the number 0.96 with the format 1pg7.1 should give the same result than with format f3.0. Thus, the result should be 1., but Gfortran produces the surprising result 0. Is it the same bug? Sincerely, Lionel GUEZ Can you please provide a short example program, and what version of GFortran you are using? I cannot reproduce the described bug with GFortran 4.4.5 nor with 4.7-20110430. Your expected result is correctly produced by the program: print (1pg7.1), 0.96 end = 1.
[Bug libfortran/48852] New: Invalid spaces in list-directed output of complex constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 Summary: Invalid spaces in list-directed output of complex constants Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net There are invalid spaces in complex constants in list-directed output: print *, (1.0, 0.0) ! ( 1., 0.) expected (1.,0.) Fortran 2003/2008: Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, depending on the magnitude x of the value and a range 10^d1 = x 10^d2, where d1 and d2 are processor-dependent integers. If the magnitude x is within this range or is zero, the constant is produced using 0PFw.d; otherwise, 1PEw.d Ee is used. Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA. The end of a record may occur between the separator and the imaginary part only if the entire constant is as long as, or longer than, an entire record. The only embedded blanks permitted within a complex constant are between the separator and the end of a record and one blank at the beginning of the next record. Part of the problem is caused by GFortran using Gw.dEe editing instead of the Fw.d editing required by the standard (i.e. appending the n blanks at the end). This is a waste of space for real constants and an outright bug for complex constant.
[Bug libfortran/48488] Wrong default format for real numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 11:24:13 UTC --- Ok, the precision is now consistently the smallest value that ensures round-trip conversion for all values. It may not always look nice, but it fulfills the Fortran standard (reasonable processor-dependent values of w, d, and e are used) with reasonable being defined by Pmin(bf) in IEEE 754/2008. It's the best we can do with this, so I'm closing this one.
[Bug libfortran/48047] Incorrect output rounding of double precision numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 11:28:08 UTC --- It is now compliant with IEEE 754/2008.
[Bug libfortran/48684] Incorrect field alignment with Gw.dEe descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 11:38:55 UTC --- The correct format according to Fortran 2008 is now used.
[Bug libfortran/48785] BOZ editing of real numbers not working with -std=f2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 12:58:42 UTC --- Created attachment 24162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24162 Proposed patch for input/output
[Bug libfortran/48785] BOZ editing of real numbers not working with -std=f2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785 --- Comment #3 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 13:01:33 UTC --- Created attachment 24163 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24163 Test case for input/output of real numbers with B/O/Z editing
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #14 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 13:24:27 UTC --- Created attachment 24164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24164 Revised patch including rounding down negative numbers Sorry, my bug report should have been more precisely: Invalid UP rounding of positive and DOWN rounding of negative numbers. The current patch does not address the second case.
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Attachment #24138|0 |1 is obsolete|| Attachment #24164|0 |1 is obsolete|| --- Comment #15 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 13:48:02 UTC --- Created attachment 24165 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24165 More examples of up/down rounding bug. There is another issue here where rounding goes wrong: It seems all values greater than 0.0 and smaller than 0.1 are rounded incorrectly with ROUND=UP; all values smaller than 0.0 and greater than -0.1 are rounded incorrectly with ROUND=DOWN.
[Bug libfortran/48785] BOZ editing of real numbers not working with -std=f2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785 --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-02 14:10:22 UTC --- Can you elaborate on this? Previously we allowed the format with -std=gnu. Now we want to allow it with -std=gnu or -std=f2008. So we call require_type() only if neither of these options is set. That's why I changed the mask from GFC_STD_GNU to (GFC_STD_GNU | GFC_STD_F2008). And the values have different bits set, so the OR is not redundant: #define GFC_STD_F2008(17)/* New in F2008. */ #define GFC_STD_LEGACY(16)/* Backward compatibility. */ #define GFC_STD_GNU(15)/* GNU Fortran extension. */
[Bug libfortran/48785] BOZ editing of real numbers not working with -std=f2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785
--- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net
2011-05-02 15:12:06 UTC ---
(In reply to comment #7)
O, I see. The important part is in
set_default_std_flags (void)
{
gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F95_DEL
| GFC_STD_F2003 | GFC_STD_F2008 | GFC_STD_F95 | GFC_STD_F77
| GFC_STD_F2008_OBS | GFC_STD_GNU | GFC_STD_LEGACY;
gfc_option.warn_std = GFC_STD_F95_DEL | GFC_STD_LEGACY;
}
So technically, we only need to test for GFC_STD_F2008, just as you said.
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-30 11:58:36 UTC --- I think for rounding up we need to test if ALL the cut off digits are zeros. One more thought: It might be (statistically) faster to scan the digits from last to first than vice versa. There are many more internal values which don't have an exact decimal representation than those that have. The quantization error will show itself in the last digits. E.g. print (f0.40), 0.1_16 ! .10048148
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #10 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-30 15:56:35 UTC --- The start to scan is the digit corresponding to d+1. e.g. PRINT (RU,F0.4), .162548148 - .1626 because48148 0 PRINT (RU,F0.4), 3.1415926536 - 3.1416 because926536 0 PRINT (RU,F0.1), 2.50 - 2.5 because0 = 0
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Attachment #24120|0 |1 is obsolete|| --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-29 07:12:10 UTC --- Created attachment 24138 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24138 Updated test for cases where d0 The suggested patch fails on examples in this test where d0. I think for rounding up we need to test if ALL the cut off digits are zeros.
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-28 06:41:27 UTC --- Created attachment 24120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24120 Testcase for F, E, G editing Bug also applies to E and G editing with non-zero scale factor.
[Bug libfortran/48511] Implement Steele-White algorithm for numeric output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-28 10:01:45 UTC ---
(In reply to comment #10)
As an addendum to the above, one thing we could do with modest effort and
without importing Gay's code would be to remove trailing zeros for G0 (and
maybe list directed) output.
For this to be useful, it would require to choose a precision of not more than
P(bf) = floor(p×log10(2)); or floor(p×log10(2)) - 1, I'm not quite sure.
That would be P = {7, 15, 19, 34} or {6, 14, 18, 33}.
We then would have a loss of precision and no guarantee of round-trip
conversion to the same number.
[Bug libfortran/48785] New: BOZ editing of real numbers not working with -std=f2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785 Summary: BOZ editing of real numbers not working with -std=f2008 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The B, O and Z edit descriptors are not accepted for output of real numbers when Fortran 2008 standard mode is selected. Fortran 2008 explicitly allows B, O and Z editing for real and complex numbers. (This is different from Fortran 2003, which only specifies B, O and Z editing for integer numbers. This has been discussed in Bug 41711.) 10.7.2.4 B, O, and Z editing 1 [...] The corresponding input/output list item shall be of type integer, real, or complex. ... 4 The value is INT (X) if the input list item is of type integer and REAL (X) if the input list item is of type real or complex, where X is a boz-literal-constant that specifies the same bit sequence as the digits of the input field. The following program, when compiled with -std=f2008 fails with: 011 At line 3 of file test_boz.f90 (unit = 6, file = 'stdout') Fortran runtime error: Expected INTEGER for item 1 in formatted transfer, got REAL (b64) ^ program test_boz print (b64), 123 print (b64), 1.23 print (b0), 123 print (b0), 1.23 print (o24), 123 print (o24), 1.23 print (o0), 123 print (o0), 1.23 print (z0), 123 print (z0), 1.23 print (z16), 123 print (z16), 1.23 print (b64.64), 123 print (b64.64), 1.23 print (b0.64), 123 print (b0.64), 1.23 print (o24.24), 123 print (o24.24), 1.23 print (o0.24), 123 print (o0.24), 1.23 print (z0.16), 123 print (z0.16), 1.23 print (z16.16), 123 print (z16.16), 1.23 end program test_boz The expected behavior is the same as without the -std=f2008 option. The program should output: 011 1110011101011110100100 011 1110011101011110100100 173 7747270244 173 7747270244 7B 3F9D70A4 7B 3F9D70A4 0011 001110011101011110100100 0011 001110011101011110100100 0173 007747270244 0173 007747270244 007B 3F9D70A4 007B 3F9D70A4
[Bug libfortran/48787] New: Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 Summary: Invalid UP rounding with F editing Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net When UP output rounding is in effect, the output of F editing is rounded incorrectly. In the example, real numbers with an exact internal representation (whole numbers) are rounded up to the next higher value. program test_ruf print (ru,f2.0), 2.0_4 ! 3. expected 2. print (ru,f2.0), 2.0_8 ! 3. expected 2. print (ru,f2.0), 2.0_10 ! 3. expected 2. print (ru,f2.0), 2.0_16 ! 3. expected 2. end program test_ruf Tested with gcc-Version 4.7.0 20110424 (experimental) [trunk revision 172919] (GCC) Fortran 2008: When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest representable value that is greater than or equal to the original value.
[Bug libfortran/48511] Implement Steele-White algorithm for numeric output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511 --- Comment #7 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-27 14:11:10 UTC --- Gay's routines (http://www.netlib.org/fp/) can handle double, float, extended, quad; rounding directions may be specified. They can output a given number of digits (compatible to all Fortran formats where this is required), thus mimicking the regular printf behaviour; or find the shortest number of digits that round-trip to the same value (good for G0 editing). This should be worth a try.
[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-26 06:40:41 UTC --- Tested ok on snapshot 20110423.
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-25 08:43:32 UTC --- The patch submitted to the list is different to the one I based my comments on. My mistake. Good work. With the current method of letting printf do the conversion, there seems to be no better way than always converting the full 40 digits, and then throwing away most of them. In Bug 48511 David Gay's dtoa implementation was mentioned. I looked into that and I think it can be modified to be fully Fortran standard compliant. It combines digit generation and rounding in one step and is probably significantly more efficient than our current solution. Will investigate further.
[Bug libfortran/48684] Incorrect field alignment with Gw.dEe descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684 --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-25 08:46:38 UTC --- (In reply to comment #5) On 04/23/2011 02:27 PM, jvdelisle at gcc dot gnu.org wrote: --- snip --- Unpatched gfortran and ifort give: I meant patched gfortran and ifort give: 12345678901234567890 0.100 1.00 10.0 100. 0.100E+4 0.100E+5 0.100E+6 0.100E+7 0.100E+8 0.100E+9 0.100E+00010 0.100E+00011 0.100E+00012 --- snip --- My question, are the values of 1.0, 10.0, and 100. formatted correctly? Yes, the number of spaces is e+2=7, so they are aligned correctly.
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 --- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-24 21:41:16 UTC --- I don't have access to a build system until Tuesday, so I couldn't test your patch. But I'm not sure I understand what you are trying to do. I see that you added one more digit in the output. I am not convinced that adding one digit will solve the problem of rounding. It will for my first test case, because it works for the values 1.1 and 1.9. But will it work for values like 1.1 or 1.9? With your patch, they will be rounded to 1.0 (or 2.0) by printf so libfortran has no way of knowing that it should round up (or down). And we recently set the maximum output width to the minimum value required by IEEE 754-2008. Increasing that further (as your patch does) will only serve in reducing the maximum rounding error from 1/1000 to 1/1 (but does not contribute to fixing this bug) Can you confirm that the patch fixes all the testcases in attachment 24083? I still think my comment #2 still applies: We can only use this shortcut rounding if the requested rounding mode equals that of printf, which I found to be NEAREST with __mingw_printf and COMPATIBLE with MSVC printf. Others, e.g. glibc probably have one of these modes, but I couldn't yet find out if this feature is documented at all.
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615
--- Comment #1 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-23 07:49:33 UTC ---
I think I found the problematic code in write_float:
if (f-format == FMT_F || f-format == FMT_EN || f-format == FMT_G
|| ((f-format == FMT_D || f-format == FMT_E)
dtp-u.p.scale_factor != 0))
{
/* Always convert at full precision to avoid double rounding. */
ndigits = MIN_FIELD_WIDTH - 4 - edigits;
}
else
{
/* The number of digits is known, so let printf do the rounding. */
if (f-format == FMT_ES)
ndigits = f-u.real.d + 1;
else
ndigits = f-u.real.d;
if (ndigits MIN_FIELD_WIDTH - 4 - edigits)
ndigits = MIN_FIELD_WIDTH - 4 - edigits;
}
let printf do the rounding means the result will always be rounded according
to the rounding rules of printf, which is for GLIBC: If the value being
printed cannot be expressed accurately in the specified number of digits, the
value is rounded to the nearest number that fits.
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-23 11:06:28 UTC --- The second branch (let printf do rounding) should only be choosen if the requested rounding mode is the same as printf uses (nearest/compatible?) and either - the format is ES or - the format is D, E or G; and the scale factor is 0. I am unsure about the last requirement (scale_factor==0); isn't the number of digits known even if the scale factor is != 0?
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #43 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-23 11:44:45 UTC --- It seems the required changes would fit in nicely in output_float(): We can treat FMT_G like FMT_E. After the rounding step, i.e. when the final value of the variable e in output_float() is known (at the label 'skip'), if e is within limits for F editing, revert the formatting to F and add the blanks at the end.
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 --- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-23 13:19:46 UTC --- Created attachment 24081 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24081 Revised test case
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Attachment #24081|0 |1 is obsolete|| --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-23 17:04:14 UTC --- Created attachment 24083 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24083 Yet another revised test. Found more bugs, even with COMPATIBLE rounding. Tested with the equation.com build (MinGW). Please report if results on other platforms differ. Results obtained are in the comments.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #41 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-21 16:36:14 UTC --- Actually it may be even simpler than that: We already know how many significant digits (d) we want in the output string, and at what digit to round. So we can write the digits of the significand into a buffer (with Ew.d editing). All that would remain is to decide whether to print the exponent or not (according to a simple integer comparison), otherwise shift the decimal point to the right place (simple string operation). E.g. 0.0995 with RU,G0.2 dtoa - .10, exponent=0 output - .10 12345000 with RD,G0.4: dtoa - .1234, exponent=8 output - .1234E+08 because exponent d 12345678.95 with RD,G0.9: dtoa - .123456789, exponent=8 output - 123456789. because exponent d
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #37 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-20 06:43:37 UTC --- The same issue exists with the first comparison (decision between FMT_E and FMT_F). Consider: print (g35.25), 0.095d0 ! 0.95..11..E-01 print (g35.25), 0.095_10 print (RC,G15.1), 0.095d0 ! 0.1E+00 expected 0.1 print (RC,F11.1,4X), 0.095d0
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #38 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-20 12:38:53 UTC --- As an alternative we might consider leaving the code as it was before and instead putting OUTPUT_FLOAT_FMT_G(4) OUTPUT_FLOAT_FMT_G(8) OUTPUT_FLOAT_FMT_G(10) into separate files and compile with -mpc32 -mpc64 -mpc80 respectively.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #32 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-19 06:09:27 UTC --- (In reply to comment #30) I can not reproduce the issue with optimization issue on my linux system x86-64. Thomas, what platform do you see the problem on? I only see it on a Cygwin installation. $ uname -a Linux debivm 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux $ ~/gcc-4.7-20110409/bin/gcc -O2 write_float.c ./a.out d=2 $ ~/gcc-4.7-20110409/bin/gcc -O2 -fexcess-precision=standard write_float.c ./a.out d=1 $ ~/gcc-4.7-20110409/bin/gcc --version gcc (GCC) 4.7.0 20110409 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. uname -a windows32 theta 2.5.1 2600 i686-pc Intel unknown MinGW gcc -O2 write_float.c .\a.exe d=2 gcc -O2 -fexcess-precision=standard write_float.c .\a.exe d=1 gcc --version gcc (GCC) 4.7.0 20110409 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libfortran/48684] New: Incorrect field alignment with Gw.dEe descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684
Summary: Incorrect field alignment with Gw.dEe descriptor
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net
With a Gw.dEe descriptor the output is formatted incorrectly if the F
conversion is selected and an exponent width e4 is selected.
The conversion in this case is F(n-4).(d-x).n('b')
The constant n is required by Fortran 2008 to be e + 2.
But it is incorrectly calculated by GFortran as min(e, 4) + 2
print (g15.3e5), 0.1d0
print (g15.3e5), 0.1d12
Output:
0.100
0.100E+00012
Expected output:
0.100
0.100E+00012
[Bug libfortran/48682] Incorrect field justification with Gw.d edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48682
Thomas Henlich thenlich at users dot sourceforge.net changed:
What|Removed |Added
CC||thenlich at users dot
||sourceforge.net
--- Comment #1 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-19 14:53:08 UTC ---
The observed behaviour is completely conforming to Fortran 2008:
10.7.5.2.2 Generalized real and complex editing
4 ... Equivalent Conversion: F(w-n).(d-1),n('b')
where b is a blank, n is 4 for Gw.d
and that complete field (including the 4 spaces) is correctly right-justified
according to the mentioned rule in 10.7.2.1
Case closed.
[Bug libfortran/48684] Incorrect field alignment with Gw.dEe descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48684
--- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-19 14:59:36 UTC ---
(In reply to comment #1)
Isn't this related to PR 48682 ?
Just a coincidence. BTW PR 48682 can be closed as invalid.
BTW: Above should read: The conversion in this case is F(w-n).(d-x).n('b')
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #23 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-18 05:59:55 UTC --- Created attachment 24025 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24025 Updated test
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #22 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-18 05:59:14 UTC --- (In reply to comment #7) + case ROUND_ZERO:\ +r = sign_bit ? 0.0 : 1.0;\ This should read: r = sign_bit ? 1.0 : 0.0;\ Attaching modified test.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #24 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-18 06:32:06 UTC --- call check_all(0.995_RT, 15, 2, 0) This still fails (with RC,G15.2 /= RC,F11.1). We need to look at why. I am aware that N=.995 is .994... internally, but so is the value 1 - r x 10^-d and 1 - r x 10^-d = N must still be true.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #26 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-18 08:40:12 UTC --- Created attachment 24027 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24027 Test program for optimization
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #25 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-18 08:39:17 UTC --- After some testing, I found the problem to be optimization-related. It seems the following term is calculated as a long double and not rounded before the if (m temp) comparison, resulting in an unexpected and in this case invalid result. temp = calculate_exp(mid - 1) * (1 - r * rexp_d); Compare: $ gcc -O2 write_float.c ./a.out d=2 $ gcc -O2 -fexcess-precision=standard write_float.c ./a.out d=1
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #17 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-17 13:25:25 UTC --- (In reply to comment #16) I see another rounding issue with this: integer, parameter :: RT=8 print *, 0.09_RT, RD: print (RD,G15.2), 0.09_RT print (RD,E15.2), 0.09_RT print (RD,D15.2), 0.09_RT print (RD,F15.2), 0.09_RT end Gives: 8.99967E-002 RD: 0.89E-01 0.90E-01 0.90D-01 0.08 I believe the E and D case should be 0.89E-01 and 0.89E-01 I agree. Let's open a new bug for this. This bug is about the correct choice of format, not about rounding (this is somewhere else in the code).
[Bug libfortran/48651] DTOA float conversion issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48651
--- Comment #3 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-17 18:34:15 UTC ---
(In reply to comment #2)
hmm, notice the typo! i have set ldnum to 0.0 but it still is printing the
value of dnum. What am I doing wrong.
$ cat sprint.c
#include stdio.h
int
main ()
{
float num = 0.9;
double dnum = 0.9;
long double ldnum = 25.6;
printf(%50.48f\n, num);
printf(%50.48lf, %d\n, num, sizeof(num));
printf(%80.78f\n, dnum);
printf(%80.78lf, %d\n, dnum, sizeof(dnum));
printf(%80.78f\n, ldnum);
printf(%80.78lf, %d\n, ldnum, sizeof(ldnum));
Check your format strings, use lf only for long double.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-16 06:42:52 UTC --- (In reply to comment #7) - if ((m 0.0 m 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) = 1.0) ||\ + if ((m 0.0 m 0.1 - r * rexp_d) || (rexp_d * (m + r) = 1.0) ||\ This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r. m 0.1 - 0.1 * r * rexp_d m 0.1 * (1.0 - r * rexp_d)
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #10 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-16 15:46:14 UTC --- (In reply to comment #8) (In reply to comment #7) - if ((m 0.0 m 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) = 1.0) ||\ + if ((m 0.0 m 0.1 - r * rexp_d) || (rexp_d * (m + r) = 1.0) ||\ This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r. m 0.1 - 0.1 * r * rexp_d m 0.1 * (1.0 - r * rexp_d) Jerry, there is a bug in your patch: You replaced 0.05 with r. This is not correct. In the original code the constant which is now r had a value of 0.5. So you must replace 0.05 from the original with 0.1 * r, which can be written either: if ((m 0.0 m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) = 1.0) ||\ or if ((m 0.0 m 0.1 * (1.0 - r * rexp_d)) || (rexp_d * (m + r) = 1.0) ||\ Please post a corrected patch, so we are testing the same thing.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #14 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-16 17:28:16 UTC ---
(In reply to comment #13)
OK, here is what I have settled on for the IF clause after checking the
factoring.
rexp_d = calculate_exp_ ## x (-d);\
if ((m 0.0 m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) = 1.0) ||\
((m == 0.0) !(compile_options.allow_std GFC_STD_F2003)))\
{ \
newf-format = FMT_E;\
newf-u.real.w = w;\
newf-u.real.d = d;\
newf-u.real.e = e;\
nb = 0;\
goto finish;\
}\
Regression testing now.
Just noticed:
Shouldn't the last term in the if clause be:
compile_options.allow_std (GFC_STD_F2003 | GFC_STD_F2008)
Fortran 2008 requires the F conversion for a magnitude of 0.0.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #15 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-16 17:45:05 UTC --- And maybe for performance improvement we should transform if ((m 0.0 m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) = 1.0) ||\ ((m == 0.0) !(compile_options.allow_std GFC_STD_F2003)))\ to: if (m 0.0 ((m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) = 1.0)) ||\ ((m == 0.0) !(compile_options.allow_std GFC_STD_F2003)))\ for m == 0.0 this avoids evaluation of (rexp_d * (m + r) = 1.0)) which is then always false anyway.
[Bug libfortran/48615] New: Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 Summary: Invalid UP/DOWN rounding with E and ES descriptors Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The E and ES descriptors ignore the I/O rounding mode: print (RU,F17.0), 1.1 print (RU,G17.1), 1.1e9 print (RU,E17.1), 1.1e9 ! 0.1E+10 expected 0.2E+10 print (RU,ES17.0), 1.1e9 ! 1.E+09 expected 2.E+09 print (RU,EN17.0), 1.1e9 print (RD,F17.0), 1.9 print (RD,G17.1), 1.9e9 print (RD,E17.1), 1.9e9 ! 0.2E+10 expected 0.1E+10 print (RD,ES17.0), 1.9e9 ! 2.E+09 expected 1.E+09 print (RD,EN17.0), 1.9e9 end Fortran 2008: 10.7.2.3.3 E and D editing 4 ... - x1 x2 ... xd are the d most significant digits of the internal value after rounding (10.7.2.3.7); 10.7.2.3.5 ES editing 5 ... - y is a decimal digit representative of the most significant digit of the internal value after rounding (10.7.2.3.7); - signifies a decimal symbol (10.6); - x1 x2 ... xd are the d next most significant digits of the internal value after rounding; 10.7.2.3.7 I/O rounding mode 3 When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest representable value that is greater than or equal to the original value. When the I/O rounding mode is DOWN, the value resulting from conversion shall be the largest representable value that is less than or equal to the original value.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #3 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-15 19:58:55 UTC --- (In reply to comment #2) I am missing something here: print (RU,G15.2), .991d0 prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 .991 with r = 1 because of UP rounding mode We are asking for two decimal digits in g15.2 above so 1.00 looks right to me. No. The d in G editing describes the number of significant digits, not the number of decimal digits. Fortran 2008: 10.7.5.2.2 states clearly (first table in clause 4) that for a value which rounds to a value greater or equal to 1 and smaller than 10 the equivalent conversion is F(w-n).(d-1) and n blanks. Thus the number of significant digits is d, because 1 digit comes before the decimal separator and (d-1) digits after it. GFortran does it right in most cases, except the ones described in this bug: UP/DOWN rounding with values close to 1 (or other powers of 10) which would round differently if COMPATIBLE rounding was in effect.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #5 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-15 20:41:02 UTC --- (In reply to comment #4) OK I knew I was looking at it wrong. The formulas you mention we are using and are in write_float.def starting at line 798. The table is there as well. I have been exploring the code here but have not spotted it yet. The issue could either be in this formula implementation or in the rounding code which is nearby. Ok, found something: The table has 0.5 hardcoded instead of the correct (rounding-mode dependent) r. And the code in line 836 (and 858?) also.
[Bug libfortran/48602] New: Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 Summary: Invalid F conversion of G descriptor for values close to powers of 10 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net Created attachment 23976 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23976 Test case Libfortran does not correctly implement the G conversion method from Fortran 2008 10.7.5.2.2(4) for the UP and DOWN I/O rounding modes. The number of significant digits d is incorrect in some cases where the magnitude of the internal value is close to a power of 10. For instance print (RU,G15.2), .991d0 prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 .991 with r = 1 because of UP rounding mode print (RD,G15,2), .996d0 prints 0.9 but expected is 0.99 because .996 1 - r * 10**-2 with r = 0 because of DOWN rounding mode
[Bug libfortran/48589] New: Invalid G0/G0.d editing for NaN/infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48589 Summary: Invalid G0/G0.d editing for NaN/infinity Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net Created attachment 23972 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23972 Test case For NaN and infinity, the form of the output field for the G0 and G0.d edit descriptors is set to a fixed width of 25, but Fortran 2008 demands: 10.7.5.2.2 3 For an internal value that is an IEEE infinity or NaN, [...] the form of the output field for the G0 and G0.d edit descriptors is the same as for F0.0.
