https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- After all that has been said here, I am almost afraid to add any more. This is not a bug. Fortran and GFortran are not locale aware. The ',' or '.' are read from the file or device literally as is. From this read, a numeric string is constructed. If the unit was opened with decimal='comma' and a comma was seen, the comma is converted to '.'. If decimal='point' and a comma is read, an error occurs. After the above described numeric string is constructed it is passed to the glibc library strtod (sring to double). The glibc library is locale aware and if the locale has defined the decimal token to be a ',' (comma), it see the decimal 'point' and interprets it as end of string conversion. We do not want to take a performance it by checking the locale setting on every I/O operation, so the only logical place to do that is in main.c. However, in the example, the original poster is only compiling a gfortran subroutine. There is no gfortran program, so there is no gfortran main.c So the responsibility for addressing the locale has to fall on the C program side or within the users subroutine using maybe system calls that are extensions and not Fortran standard code. This users code would query the current runtime environment for current decimal setting and then do the I/O with the appropriate decimal= specifier. To avoid confusion, remember that gfortran is reading the characters in the file literally. So if there is a 1,2345 it sees the comma. If there is a 1.234 it sees the point. The conversion to internal floating point representation occurs after the character data is read. The easiest solution is to do what I said in in Comment #2 on the C side. The equivalent can be done on the fortran side as well, just not as easily. One possible enhancement we could consider is providing some set and get locale intrinsics. This would be helpful for some folks. But, thats a lot more work.
