- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Up to and including ifort/ifx 2021.2.0, the following code prints inconsistently:

```
% cat ifort-g-fmt-bug.f90
double precision :: x = 100., d = 0.01_8
print '(3g11.3)', x + d, x, x - d
end
% ifort ifort-g-fmt-bug.f90 && ./a.out
100. 100. 100.0
```

Note that the third column should also read "100." without any decimal. Likely an internal double rounding issue with the g format.

Thanks,

Harald

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Yeah, something is weird here. I note that NAG Fortran gives the "100." output you expect. This part of the standard was completely overhauled for Fortran 2018, as we felt the earlier table-based description was incomprehensible. So I changed my mind - this is indeed a bug.

And, yes, @andrew_4619 , I did copy and paste that.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Not a bug.

The standard says, "If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the input/output rounding mode and let s be the integer such that 10**(s−1) ≤ |N| < 10**s . If s < 0 or s > d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively, where k is the scale factor (13.8.5). If 0 ≤ s ≤ d, the scale factor has no effect and F(w − n).(d − s),n(’b’) editing is used where b is a blank and n is 4 for Gw.d editing, e + 2 for Gw.dEe editing if e > 0, and 4 for Gw.dE0 editing."

The value of x-d is 99.99, so the value of s here is 2 (10**1 ≤ 99.99 < 10**2). s (2) is not greater than d (3), and s is greater than zero, so the format used is F(11-4).(3-2) or F7.1. 99.99 in an F7.1 format outputs as 100.0.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Steve, I sincerely hope that you cut and pasted that answer.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

@Steve_Lionel wrote:

"If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the input/output rounding mode"

For g11.3 we have d=3, so what is N? I would expect 99.99 to be converted ("rounded") to 100.

" and let s be the integer such that 10**(s−1) ≤ |N| < 10**s . If s < 0 or s > d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively, where k is the scale factor (13.8.5). If 0 ≤ s ≤ d, the scale factor has no effect and F(w − n).(d − s),n(’b’) editing is used where b is a blank and n is 4 for Gw.d editing, e + 2 for Gw.dEe editing if e > 0, and 4 for Gw.dE0 editing."

This is pretty clear.

The value of x-d is 99.99, so the value of s here is 2 (10**1 ≤ 99.99 < 10**2). s (2) is not greater than d (3), and s is greater than zero, so the format used is F(11-4).(3-2) or F7.1. 99.99 in an F7.1 format outputs as 100.0.

My reading is that s=3 due to N=100. The text in the standard does not seem to determine s first, it refers to N initially, which appears deliberate to avoid the possible ambiguity 100. vs. 100.0

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Yeah, something is weird here. I note that NAG Fortran gives the "100." output you expect. This part of the standard was completely overhauled for Fortran 2018, as we felt the earlier table-based description was incomprehensible. So I changed my mind - this is indeed a bug.

And, yes, @andrew_4619 , I did copy and paste that.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

I just filed a bug reporting this, CMPLRLIBS-33394. ifx does the same (wrong) thing.

I'll keep you posted on the fix.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page