There is a minor new bug In 2017 and 2018 compilers related to parsing white space in derived types in namelist input. It did not happen in the 2015 version. Here is a simple test case:
program test TYPE ::Beam integer:: a,b character(len=8)::s end type Beam type(beam):: b namelist /surprise/ b open(10,file='test.nml') read(10,surprise) close(10) print*,b end program test
To trigger the bug, see the following input file:
&surprise b % a = 1 b % s='str' b % b = 1 ! white space surrounding % sign in line following character string /
The error is:
forrtl: severe (18): too many values for NAMELIST variable, unit 10, file /home/sdettrick/debug/test.nml, line 4, position 4
To hide the bug, replace "b % b" with "b%b". The code then runs fine.
It seems that no white space is permitted on either side of the % sign for namelist entries that follow a namelist entry that specifies a character string. Whitespace is otherwise permitted.
The workaround is to follow the new rule: No white space is permitted on either side of the % sign if the preceding entry specifies a string.
That's not a compiler bug, it's an error in your input. The standard says (emphasis mine):
"Each object designator shall begin with a name from the namelist-group-object -list (5.6) and shall follow the syntax of designator (R601). ... Each designator may be preceded and followed by one or more optional blanks but shall not contain embedded blanks."
Thank you for the clarification. I won't argue on the standard, as that would require me to read it first! But it is peculiar that that part of the standard is only applied on lines that immediately follow a string assignment.
Probably a side-effect of fixing a bug elsewhere. It seems an odd thing to me to put whitespace in the middle of the "designator" - you would not typically do that in code, and a namelist write doesn't put spaces in.