Martin Reinecke wrote: > > The attached testcase requires gcc and gfortran, as well as a JDK > installation. When running "make" with gcc/gfortran 4.7.2 and > Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the > behaviour of subsequent READ statements in the Fortran code, > depending on the value of the LC_ALL environment variable. > > If this is a bug (it certainly feels like one to me), do you think > it is fixable in either gcc or the Java libraries, or is this > some unfortunate interaction that cannot really be fixed? > If there is something that can be done in gcc, I'll be happy to open > a full bug report.
It sounds like the following bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 libgfortran calls libc's strtof/strtod/strtold/libquadmath's strtoflt128 to convert the number. And that function is locale dependent - but gfortran assumes that it uses a "." as decimal separator. It's surely fixable - the question is only what's the best approach. I see the following possibilities: - Ignore the issue (not the best approach but the simplest. Also known as: The compiler user has to handle it.) - libgfortran should have its own parsing of the string. - (Temporarily) reset the local setting before calling strtof/strtod/strtold/libquadmath - Convert the input to the used locale before calling strtof/strtod/strtold/libquadmath I am in favour of the last option. The first one is the best current solution for you (sorry!): Handle the locale issue it yourself. Tobias
