Erroneous remark about the format used in a READ statement

[Arjen_Markus]

The current compiler issues remarks about formats where the specified width is too small for the specified decimal part, like E12.7. However, it does so for output formats and input formats , whereas for input formats the relation is completely different, especially something like E12.0.

Here is a small program that demonstrates the issue:

program chkinput
    implicit none

    real :: x

    read(*, '(e20.0)' ) x

end program chkinput

The output from the compiler is:

Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.1.0 Build 20230320
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

chkinput.f90(9): remark #8577: The scale factor (k) and number of fractional digits (d) do not have the allowed combination of either -d < k <= 0 or 0 < k < d+2. Expect asterisks as output.
    read(*, '(e20.0)' ) x
------------------^
Microsoft (R) Incremental Linker Version 14.36.32532.0
Copyright (C) Microsoft Corporation.  All rights reserved.

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

There is no sensible way of specifying the format, so that it works without surprises - a number without a decimal point should not be interpreted with a decimal point inserted somewhere arbitrary, hence the 0 number of decimals - and with no remark from the compiler.

A related issue:

The statement

   read( '12345', '(f5.2)' ) x

gives rise to the following error messages:

chkinput.f90(13): error #6899: First non-blank character in a character type format specifier must be a left parenthesis.   ['12345']
    read( '12345', '(f5.2)' ) x
-----------^
chkinput.f90(13): error #6324: This specifier has already been used in this I/O operation.
    read( '12345', '(f5.2)' ) x
^
compilation aborted for chkinput.f90 (code 1)

I know it is wrong, but the error messages are not very clear about what is wrong.

[Barbara_P_Intel · Accepted solution]

Thanks for pointing this out, @Arjen_Markus. Those messages read like the standard! Apologies to those that understand the ins/outs of the standard documents.

I filed a bug report, CMPLRLLVM-57632, we'll let you about any updates.

[Arjen_Markus]

You're welcome. We ran into it trying to clean up our code and if you want to solve such remarks, then it becomes necessary to use a different format AND running the risk that numbers are interpreted differently (which is, I humbly think, worse than having a spurious remark from the compiler :)).