https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90150
--- Comment #4 from federico <perini at wisc dot edu> --- uhm so that is my fault, I guess - sorry about that. Apparently this is what the FORTRAN standard features. Still, I’m a bit confused that the P descriptor produces only a format change with the E format, while leading to a _value_ change with F. Federico Perini ________________________________ From: sgk at troutmask dot apl.washington.edu <gcc-bugzi...@gcc.gnu.org> Sent: Thursday, April 18, 2019 9:40:05 PM To: Federico Perini Subject: [Bug fortran/90150] wrong output produced by float format fX.Y descriptor following translated scientific format XpeY.Z https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90150 --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Thu, Apr 18, 2019 at 07:27:31PM +0000, perini at wisc dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90150 > > --- Comment #2 from federico <perini at wisc dot edu> --- > Number b=10.0, so in format f8.3 it should always be output as “ 10.000” ? Ahem, no. 1p changes the scale factor by 10. 2p changes scale factor to 100. The scale factor is a property of the output connection. So, 1p and 2p apply to both e10.3 and f8.3 in your format strings. >> $ a.exe >> 0.100E+04 10.000 ! "(1e10.3,1x,f8.3)" >> 1.000E+03 100.000 ! "(1pe10.3,1x,f8.3)" Perhaps, you want '(1pe10.3,1x,0pf8.3)' >> 10.00E+02 1000.000 ! "(2pe10.3,1x,f8.3)" Perhaps, you want '(2pe10.3,1x,0pf8.3)' > Can you explain what you think the compiler should output? > > The P edit descriptor affects the entire string not just > the immediately following edit descriptor. -- You are receiving this mail because: You reported the bug.
