Incorrect parsing of NAMELIST variables?

[ereisch]

Using ifort 12.0.0, MKL 2011.1.107

I have a program that is producing different behavior on different systems. I have a namelist with invalid syntax that is (at least in some cases) reading in values improperly rather than exiting with a parse error as would be expected.

In case 1, I have a variable declared as an INTEGER*4 as a NAMELIST member, however in the input file namelist, the variable is defined as 18.0. When run on a Debian/GNU Linux 5.0 system (libc6 version 2.7), the READ() call successfully parses the data, and the variable in question is set to 18 (unexpected behavior). However, on a RHEL 5 system (libc6 version 2.5), the program exits with a syntax/parse error on the line defining that variable as 18.0 (expected behavior).

There was a second case for which I unfortunately do not have exact details, but it was very similar. I believe the value was 25.0, but I'm not positive. Again though when run on a Debian system it would parse in the value and store the proper number (25) in the INTEGER variable, however on a RHEL system it would "successfully" parse the value, but would instead store an incorrect value of "4" into the INTEGER variable, and processing would continue.

Upon changing the value in the NAMELIST of the config file back to 25 (vs. 25.0), both systems properly read and store the value.

[Steven_L_Intel1]

You're using the same version of ifort on all these systems? We support any numeric type as the value when reading a numeric (INTEGER, REAL, COMPLEX) item in NAMELIST and list-directed input and convert the value according to the rules of intrinsic assignment. This is an extension to the standard. I would be more surprised to get an error if you were indeed using ifort and not, say, gfortran (I don't know what gfortran does here.)

Either behavior would be correct. As I am known to say repeatedly, you must not depend on getting an error from list-directed or NAMELIST input for what YOU think is "malformed" input. Implementations are allowed to be more permissive than the standard and many are.

I will note as a side comment that we used to allow logical constants as input for numeric values, and vice versa, but eliminated that in version 11.1 (with an option to allow it).

[ereisch]

No, we don't even have gfortran installed on these systems (because we use UNIONs which aren't supported with that compiler). And yes, all are using ifort 12.0.

My concern is more the different behavior on the two systems......if it is going to convert 12.0 to an INTEGER automatically, that's no problem. However the one case (which took us several days to track down) of it taking in 24.0 and assigning "4" to the variable is also a point of concern. When we ran that program on one system it assigned the wrong value to the variable, and on a different system it worked fine. When we went into the input file and fixed the value to be 24 instead of 24.0, it worked fine on both systems.

For reference, our compile flags are:
-extend-source 132 -assume nounderscore -assume nobscc -align dcommons -static-libgcc -zero -fp-port -save -c -fpe0 -ftz -prec-div -fp-stack-check -ccdefault fortran -traceback -fp-model precise -xSSE2 -axSSE2 -g -debug full -debug-parameters -check bounds -O0 -m32

...and our link flags are:
-static-libgcc -Wl,-d -Wl,--sort-common -Wl,-export-dynamic -Wl,-Map -Wl,link.map -m32 -o prog.glx -Wl,--start-group lib1.a lib2.a lib3.a -lcurses -Wl,--end-group

[Steven_L_Intel1]

That's very interesting. I am going to ask one of our other support engineers, more familiar with Linux, to help you with this. We will need a test case (source and probably the binary you are using) as well as an input file.

[krothhaar]

We are having a similar issue here in an application when we upgraded from 9.1 to 12.1. The same exectuable on the same system(windows XP) can behave differently. Sometimes it reads a value of 1.0 as 1 and other times it reads it as 4. Do we know why the "4" keeps coming up? Even if we set the value to 204532.0 it shows up as 4.

[Steven_L_Intel1]

Without a test case, we don't know. Can you provide one? (Source and input, not an EXE.)

[Alexandra_H_]

I have seen the same behaviour as krothhaar. When using namelist input, sometimes integer values, which are given for example as 123.0 (not as 123), will not be converted to 123 (as expected). The value wich is assigned to that integer variable seems to be random.
It seens, that there is an influence of the order of the input variables in the input list.
If I use input file 1, int2  will get the same value as int1 (int2 is listed directly after int1).
If I change the order in the inputlist like in input file 2, int2 will get some kind of random value.

I am using Intel(R) Visual Fortran Compiler XE 14.0.2.176 [IA-32]. I have seen the same, when using Intel(R) Visual Fortran 11.1.065 (Windows 7)

      program namelist_int
      implicit none
      
      integer  int1, int2
      double precision dp
      integer io
      
      namelist /input/ int1, int2, dp
      
      
      
      open(10, file = "input.txt", iostat = io)
      if (io /= 0) stop "error opening input.txt"
      
      read(10, nml = input, iostat = io)
      if (io /= 0) stop "error reading from input.txt"
      
      close(10)
      
      open(20, file = "output.txt", iostat = io)
      if (io /= 0) stop "error opening output.txt"
      
      write(20, nml = input, iostat = io)
      if (io /=0) stop "error writing on output.txt"
      close(20)      
        
      write(*, nml = input)


      end program namelist_int

Input file1:

&input
int1 = 10
int2 = 44444.0
dp = 9d0
/

after reading, the value of int2 is 10.

Input file 2:

&input
int1 = 10
dp = 9d0
int2 = 44444.0
/

after reading, the value of int2 is 8.

[mecej4]

Alexandra H. wrote:
after reading, the value of int2 is 8

On what basis do you say this? How do you you observe the value of INT2? In a debugger? Which one?

I compiled and ran your example with the 14.0.2 compiler on Windows, in 32-bit and in 64-bit modes; I saw no errors in the output or in the debugger.

Please provide enough information to enable us to reproduce the error. For starters, report the compiler options used, and give additional information about the OS version, VS version, etc.

[Alexandra_H_]

For ifort 14.0.2.176 and VS2008 I now switched the configuration from debug to release with the following options:

/nologo /O2 /warn:interfaces /module:"Release\\" /object:"Release\\" /Fd"Release\vc90.pdb" /libs:static /threads /c

Now it works as expected: the value of int2 is now 44444

It seems to be a problem with the debug configuration.