https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Khang H. Nguyen from comment #0)
> For this bug I report, I report two bugs. One could be a potential bug while
> the other should for certainly be a bug. These bugs affect both, gfortran
> version 7.3.0 and gfortran version 8.2.0.
>
> Bug one(Potential bug):
>
> When using the read() procedure for parsing a string to an integer type,
> strings, where valid digits follow by whitespaces and then any other
> character, are parsable. I don't think they should be parsable as those
> strings are not valid number strings. For example:
> 1. " 12 b " >> will become 12
> 2. " 124 c " >> will become 124
(Nit: read is not a procedure, it is a statement).
This is the way it is supposed to work if you are using list-directed
input, the space acts like a separator. It's a bit like the
behavior of C's scanf() in that respect.
> Bug two:
>
> It is not possible to assign the lowest value to any integer type without
> having no range check disable as the compiler will give false warning. For
> example -2147483648 can't be assigned to int32, -9223372036854775808 can't
> be assigned to int64, and -170141183460469231731687303715884105728 couldn't
> be assigned to int128.
gfortran's behavior correct according to the Fortran standard.
-2147483648 is parsed as - (2147483648), and 2147483648 is
outside the symmetric range of numbers. This is why we have an
option to disable range checking.
