G format in

G format in


Hello, I am facing an overflow issue with the aforementioned version of the compiler for the following program.

With i had the correct text in tchar: was i lucky?


    program fortranformat


    implicit none


    ! Variables


     real*4 r


    ! Body of fortranformat

    print *, 'Hello World'

    r = -1.0

    write(TCHAR,'(G12.6)')     R


    end program fortranformat

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I think that you have exposed a new bug in IFort 2013. According to, in particular the table shown there, which is reproduced in the IFort Reference Manual, for the value of -1.0, the format should be according to the following line, with n=4 as noted after the table.

     1 − r × 10−d ≤ N < 10 − r × 10−d+1      F(w − n).(d − 1), n(’b’)

You specified G12.6, so the format used should be F8.5 followed by four blanks.

I am also of the opinion that in this case the following compile time remark is not warranted (the remark would be warranted if the value were such that an Ew.d or Ew.dEe format would be selected):

gform.f90(9): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.

According to of the Fortran 2003 standard, the value -1.0 when printed with G12.6 should be printed according to this line in the table:

1 − r × 10-d ≤ N < 10 − r × 10−d+1                F(w − n).(d − 1), n(’b’)

with F8.5 followed by four blanks. Furthermore, the following remark from the compiler is a case of crying "wolf" when the number N being printed and the w and d in the G format do not cause the output to occur in Ew.d or Ew.dEe formats.

gform.f90(9): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.

I think this language feature has had more changes in the standard over time than anything else.  It changed twice in F2003, again in F2008 and there was very recently an approved interpretation that changed it once again. Your particular example demonstrates an edge case where a difference can be seen.

The current compiler implememts what F2008 says, and the complicating factor is the "r" in the text cited by mecej4. What is this?  It's a fudge factor to take rounding modes into account. The default is "round to nearest" - the text in the standard says that r is 0.5 "if the higher value is even" and -0.5 "if the lower value is even", without defining what it means in this context, but I think we use -0.5 here.

Going through all the motions ends up with a format of F8.6 followed by 4 blanks, and -1.0 doesn't fit into that, hence the asterisks.

Interpretation F08/0055 greatly simplified the rules here and moved the consideration of rounding to before conversion rather than after conversion. Here's what the new text says:

If the internal value is a zero value, let s be one. 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 I/O rounding mode and let s be the integer such that 10^(s-1) <= N < 10^s. If 0<=s<=d, F(w-n).(d-s),n('b') editing is used where b is a blank and n is 4 for Gw.d editing and e+2 for Gw.dEe editing. If s<0 or s>d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively.

Let's walk through this. N here is 1.00000, or 1 to 6 significant digits. The sign and rounding mode is no longer relevant (though they were before). Now what's the value of s? it is 1, since 10^(1-1) or 10^0 is 1 which is <= 1 and < 10^1 (or 10). Since 0<=1<=6, F(12-4).(6-1),4('b') or F8.5 followed by 4 blanks is used which is what you want. We have implemented this for a release later this year.

Now what to do in the meantime? Remember the rounding issue?  You can change the rounding mode and what you want is "compatible" rounding. So do this:

write(TCHAR,'(RC,G12.6)')     R

You'll now get the answer you want.

For some of the gory details, see http://j3-fortran.org/doc/year/13/12-006Ar1.txt and search for 08/0055.

Retired 12/31/2016


Thanks for the (almost gory) details.

I apologize for the two nearly identical postings; I clicked 'submit' on the first and, a few minutes later, noticed that it had not appeared and tried a second time. This time, I noticed a somewhat inconspicuous line that said that the post awaited approval. Perhaps  something more prominent would have caught my attention.


Dear All,

Thank you for your replies.

The work around works for both ifort 13 and ifort 12 as expected.

Leave a Comment

Please sign in to add a comment. Not a member? Join today