Namelist format issue with ifort crashes fpm

1

Hello all,

I’m working to extend Intel compiler support for fpm, as part of a broader effort to enable oneAPI + IntelMPI as an automated package.

Currently, fpm cannot run the tests due to an issue with this namelist, whose minimum example is:

program nml_test
implicit none
character, parameter :: NL=new_line('a')
character(:), allocatable :: crashes,cmd,profile,args
integer, parameter :: max_names = 10
integer :: i
character(len=15), allocatable :: name(:)
namelist /settings/cmd,name,profile,args

! Init variables
name=[(repeat(' ',len(name)),i=1,max_names)] 
cmd=repeat(' ',132)
profile=''

crashes = '&SETTINGS '//NL//&
          'CMD="build", NAME=, profile="",ARGS="", ' //NL//&   ! CRASH AT THIS LINE
          ' /'
read(crashes,nml=settings)
end program

returning

forrtl: severe (17): syntax error in NAMELIST input, unit -5, file Internal Formatted NML Read, line -1, position 38

The issue is that NAME= has no delimiter for the character variable, and is not followed by a comma before profile. gfortran builds and runs this line OK.

I would like to ask the community if I have stumbled upon a compiler issue, or instead the namelist text format is wrong? If I add a comma after NAME, then everything works:

          'CMD="build", NAME=, profile="",ARGS="", ' //NL//&   ! Works

this example is also on Godbolt.

Thank you in advance for the pieces of advice!

1 Like
2

Even with the standard description I have seen arguments on this, and even whether allocated allocatable variables are allowed; whether the comma is required between keyword=value(s) pairs, whether even if delim is specified you can still have unquoted character values, … . One, it is always a good idea to specify the DELIM= on and WRITE , or at least on the OPEN (which maybe it was). I think it is ifx that fails if you do not have a comma even on the last entry, and I have seen failures if"&" is not in column 1 or if any other line does not have column 1 blank, even for comments. There have also been questions as to whether character variables that exceed the variable length should be trimmed or cause an error, … I thing I would just change it to NAME=" “, (also used to be questions about whether at least one character was required or if two adjacent “” were allowed so I would have at least one space in the string and work around it. Then, as a separate action maybe ask the committee for clarification. I am not in a place where I can check the standard or test at the moment, but I would even change the ARGS=”" to " " as well and get the tests going with that (assuming that works) for now. I will double-check what I am suggesting when I can review the docs; but at least in a few versions there was room for debate on a few issues; maybe the latest rev clears up some of these, though.

It is always interesting with NAMELIST to set the values and write them to see how that particular compiler formats it; and then see if it can read back in what it wrote. Not always a given it can.

Last I had access, the IBM compiler required &NAME and / to be on lines by themselves on input, so three lines were required to change a value minimum, even with internal READ. Not sure if that is still true, but used to have to work around that when internal read and write first became available.

3

My pet issue! I have advocated about this many times.

The standard insists that the delimiter come from the open statement, and defaults to delim=NONE, even if you have opened a namelist. Any strings written to the namelist will have no delimiters.

And yet! If you look at the standard’s definition of a namelist, it requires that strings have delimiters, presumably to avoid scenarios such as the one you encountered.

This is always a surprise to users of Intel, which dutifully follows the standard.

As for why it doesn’t happen in Gfortran: it deliberately does not follow the standard and uses a delimiter (I think QUOTE).

Whenever I have raised this, I’m usually told that it’s “too late” to do anything about it. But if you disagree, please add some noise to this issue.

1 Like
4

I don’t think that is true now for standard fortran namelist. Here is a short example that works for at least a couple of other compilers.

program name
   implicit none
   integer :: a=-1, b=-2
   character(len=20) :: string = '&input a=2, b=3/'
   namelist /input/ a, b
   write(*,*) 'before: a=', a, ' b=', b
   read(string,nml=input)
   write(*,*) 'after: a=', a, ' b=', b
end program name
1 Like