Surprisingly poor g0 output with -assume noold_e0g0_format

[NCarlson]

Consider this test program

use iso_fortran_env
write(*,'(g0)') 5.67e-14_real64
end

When compiled with "-assume old_e0g0_format", which is the default with ifx, I get something reasonable:

$ ifx -assume old_e0g0_format intel-20231213.f90 
$ ./a.out
.5670000000000000E-13

But with "-assume noold_e0g0_format" which uses "F2018 formatting rules", I get this:

$ ifx -assume noold_e0g0_format intel-20231213.f90 
$ ./a.out
.6E-13

That seems awfully extreme; there's not a single correct digit there.  Can that possibly be valid?

I'll also note that "-standard-conforming" appears to imply "-assume noold_e0g0_format" even though the man page for ifx does not mention this one.

[Steve_Lionel]

There is indeed a correct digit. The standard says, "Reasonable processor-dependent values of w, d (if not specified), and e are used with each output value." and "On output, with I, B, O, Z, F, and G editing, the specified value of the field width w may be zero. In such cases, the processor selects the smallest positive actual field width that does not result in a field filled with asterisks." (emphasis mine).

The issue here, I think, is that someone at Intel took the latter part too seriously and didn't consider that a d of one was not "reasonable". I note that NAG's output is much the same as Intel's "old" output. I'd be curious to learn what prompted Intel to add this option. 

[NCarlson]

Thanks for your reply @Steve_Lionel .  I can see now that what they've done is strictly okay: when Intel decides to write the number using an exponent, the smallest field width must include a single mantissa digit, and that's what they do (rounded correctly).  1.25d-2 is written ".1E-01".  But funnily, 1.25d-1 is written without an exponent as ".1250000000000000", and so forth for larger values.  I think Intel needs to seriously rethink how they've implemented this option, which importantly is implied by -standard-semantics, so they regard this as the proper standard behavior (and not a peculiar tweak) -- which for me makes g0 unusable.

[andrew_4619]

Roll on f2023 which has some fixes for some of these standard conforming but undesirable quirks.

[Steve_Lionel]

I agree.

[Steve_Lionel]

Indeed (see j3-fortran.org/doc/year/21/21-172r1.txt) , but not for this case, where there are no changes.