Separate vector element controls are collapsed into array index, which changes results

[warrickball]

Here's a small example program that reads some numbers from a namelist:

program vector

  integer :: x(5), iounit, ierr

  namelist /controls/ x

  x = 0

  open(newunit=iounit, file='controls.in', status='old', iostat=ierr)
  read(iounit, nml=controls)
  close(iounit)

  write(*,*) x

end program vector

Here's the namelist:

&controls
    x(3) = 1
    x(4) = 1
    x(5) = 1
/

If I compile vector.f90 and run it, I get the expected output

           0           0           1           1           1

However, if I run f90nml on controls.in, it collapses the namelist input to

&controls
    x(3:5) = 1, 1, 1
/

which runs but doesn't give the expected results. If I change controls.in to the f90nml output, I instead get

           0           0           1           0           0

I'm familiar with this issue from development work, which tripped up a few users.

I'm willing to take a stab at fixing this if we agree on the desired behaviour. I think that f90nml should leave entries like this unchanged.

[marshallward]

I agree more control would be very useful, and has been suggested in other fonts issues, but the condensed namelist ought to be valid, and I get the expected result when I use gfortran.

What compiler are you using? This seems more like a compiler bug to me.

(Edit: #24 first discussed supporting per-entry output)

[warrickball]

I'm using gfortran 8.2.1 on Fedora 28.

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.2.1 20181011 (Red Hat 8.2.1-4) (GCC)

[marshallward]

Very confused.. I am also using 8.2.1.

Might be useful to backtrack: What did you use f90nml to do?

[warrickball]

D'oh! I'm so sorry! It looks like this is an error on my part. I must've messed with a file by hand. I was starting with this:

&controls
    x(3) = 1
    x(4) = 1
    x(5) = 1
/

which f90nml (correctly) collapses to

&controls
    x(3:5) = 1, 1, 1
/

This is valid an works correctly. For some reason, I was testing

&controls
    x(3:5) = 1
/

which is where the mistake comes in: I'm not supplying x(4) and x(5).

Basically, I thought I could assign a vector of parameters using a scalar, like I can in compiled code, but I'm wrong. And f90nml knows better than me!

[marshallward]

No worries! I actually had thought you stumbled on a known bug of the command line tool, but glad it's ok now :).