http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
--- Comment #12 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-02-07 07:01:14 UTC --- (In reply to comment #11) > Fixed on trunk. I don't think this is significant enough to justify a > back-port. I am not sure why anyone would use f1.X for anything, so this > exercise is largely academic. I do appreciate the bug reports. Thanks Thank you for your work on this and for the fast response, which is actually better than what you get from the "premier" support of some big commercial compiler vendors. Of course I agree with you that noone would use (F1.n) editing, that was exactly my point, see my comment #1: "Any formatting ... with (F1.n) should always result in asterisks". However, because of the rule for (F0.n) we need to make clear what is "the smallest positive actual field width that does not result in a field filled with asterisks". print "(F0.0)", 0.0 ! => 0 I'm still pretty sure that this is not compliant to Fortran 2003/2008 and I would like a convincing explanation why it should be. Of course I can understand the argument that "0" instead of "0." is useful to express the "real zero", but I think standard-compliance takes precedence, making it easier for the user to write portable programs. In my interpretation, the demand of "a string of digits that contains a decimal symbol" is equivalent to the syntax: DIGIT ... DECIMAL-SYMBOL [DIGIT] ... | [DIGIT] ... DECIMAL-SYMBOL DIGIT ... The clause "The optional zero shall appear if there would otherwise be no digits in the output field." rules out the string becoming just: DECIMAL-SYMBOL As I see it, the decimal symbol is not optional and cannot be left out, so the output "0" is illegal. The phrase "contains" means that e.g. the Java method string.contains(decimal_symbol) would return true.
