-standard-semantics switch causes the g0 descriptor to generate incorrect output

[ur]

When -standard-semantics is used on ifort or ifx the g0
format generates output I consider to be incorrect.

program main
implicit none
doubleprecision :: value
character(len=80) :: string
value=-1234.0d-20
write(string,'(g0)')value
write(*,*)trim('g0= '//string)
end program main

ifx gee.f90 -standard-semantics
$ ./a.out
g0= -.1E-16

ifx gee.f90
$ ./a.out
g0= -.1234000000000000E-16

Although the output of g0 is somewhat compiler dependent,  the output should be closer to what list-directed output generates.

[Steve_Lionel]

It took me a while to figure out that the key option here is /assume:noold_e0g0_format, which is NOT listed in the set of assume options enabled by /standard-semantics. The description of this option is "Determines whether Fortran 2018 rules are used to format floating-point numbers that have G0.0 or E0 or ES0 format edit descriptors." but not explained further. Fortran 2018 did simplify and regularize the rules for G0, but ifort/ifx isn't being reasonable here (and doesn't match nagfor, for example.) 

F2018 says, "When used to specify the output of real or complex data that is not an IEEE infinity or NaN, the G0 and G0.d edit descriptors follow the rules for the Gw.dEe edit descriptor, except that any leading or trailing blanks are removed. Reasonable processor-dependent values of w, d (if not specified), and e are used with each output value." The F2008 description was far more complicated.

I admit that the Intel result isn't non-conforming, but it is surprising and not reasonable. I'd be curious to know what this option really does (and note that the documentation needs updating.)

[FortranFan]

Intel team,

You may know this appears a change in the latest oneAPI release, see below with oneAPI 2023.0.  Is this change intended?  Or will it be considered a regression?

C:\Temp>type p.f
   print "('Using g0: ',g0)", -1234.0d-20
end
C:\Temp>ifx /standard-semantics /free p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.0.0 Build 20221201
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.31.31107.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
Using g0: -.1234000000000000E-16

C:\Temp>ifort /standard-semantics /free p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.31.31107.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
Using g0: -.1234000000000000E-16

[Steve_Lionel]

Discovered again in Is the behavior of -standard-semantics expected? - Compilers / Intel - Fortran Discourse (fortran-lang.discourse.group)

[Ron_Green]

I've escalated this to our runtime team. 

The bug ID is CMPLRLIBS-34487. I am following up with our Runtime Libraries team. For now, you can use option -assume old_e0g0_format (linux) or /assume:old_e0g0_format

[Steve_Lionel]

Thanks, Ron. Would you please ask the RTL team exactly what this option does? Also, please make sure it is added to the documentation of -standard-semantics.