for easy specification of options I have grouped them in derived types. An object of such a type is then placed in a namelist that is used for input. This works fine. However, with inherited components of extended types this approach works with ifort only when the parent type is specified, as in the example below. With gfortran this is not necessary.
program nml_input type base_type integer :: c = 0 end type base_type type, extends(base_type) :: ext_type end type ext_type type(ext_type) :: ext namelist /ext_data/ ext integer :: io open(newunit=io, file='nml_input.dat') read(io, nml=ext_data) print *, 'ext % c =', ext % c end program nml_input
Contents of the input file "nml_input.dat"
&ext_data ! ext%c = 1 ! fails with ifort, works with gfortran ext%base_type%c = 1 ! works with ifort and gfortran /
I am not sure wether this is a compiler error, or just a missing feature.
Based on the Fortran standard, Intel Fortran compiler looks conformant in this instance.
Since the derived type(s) in question do not have defined input/output procedures. per Fortran standard it's the component order that applies with NAMELIST input.
And with component order definition in the standard, the components of a parent type are excluded from the extended type and the "The component order of an extended type consists of the component order of its parent type followed by any additional components in the order of their declarations in the extended derived-type definition."
That's a bug. Both forms of the designator should be accepted. An extended type has all the components of its parent (f2018 7.5.7p1), plus access to those components of the parent type through the parent component.
Component order would only be relevant if values for multiple components were being specified in the one name/value pair (list of values on the right of the =). The standard also says "parent components are excluded", not "components of the parent".