- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :)).
![](/skins/images/54BF544B471F3F61DFD338F1D58F9426/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page