IFX BUG or standard conformance? PDT component initialization

[DataScientist]

IFX 2026.0 cannot compile the following program. Is it a compiler bug, or is the Fortran program non-standard-conforming? The primarily issue the PDT component initialization `type(pdt_comp(RKG)) :: comp = pdt_comp(RKG)(real(1, RKG))`. Commenting out the PDT component's initialization part resolves the issue.

Here is test: https://godbolt.org/z/rvfnT6bqs 

```fortran

module mod_pdt

    implicit none

    integer, parameter :: RK = kind(1.)

    type :: pdt_comp(RKG)

        integer, kind :: RKG

        real(RKG) :: x = 1

    end type

    type :: pdt_parent(RKG)

        integer, kind :: RKG

        type(pdt_comp(RKG)) :: comp = pdt_comp(RKG)(real(1, RKG))

    end type

end module mod_pdt

program main

    use mod_pdt

    implicit none

    type(pdt_parent(RKG=RK)) :: a

end program main

```

[MarcGrodent]

Interesting little application of parametrized derived types.

• The compiler errors with ifort (2021.10.0) and ifx (2026.1.1) seem (as you say) to be due to the call to the constructor (comp = pdt_comp(RKG)(real(1, RKG)). With just 'type(pdt_comp(RKG)) :: comp' declared in pdt_parent and an initialization such as 'a%comp%x = real(1, RK)' in the main program, the code runs correctly. However, I don't see why this constructor should be a problem...

• I've also tried to compile with GNU Fortran 16.2.0: in this case, the compiler generates an error at line 'real(RKG) :: x = 1' => "Cannot convert INTEGER(4) to REAL(0)". With your original code and just 'real(RKG) :: x', there is no problem and your code runs correctly. However, I think that an initialization such as 'real(RKG) :: x = 1' is allowed by the Fortran standard (to be confirmed).

Maybe all these compilers have bugs at different levels...

 It would be interesting to get @Steve_Lionel 's opinion on this issue.

[JohnNichols]

module mod_pdt

    implicit none

    integer, parameter :: RK = kind(1.)

    type :: pdt_comp(RKG)
        integer, kind :: RKG
        real(RKG) :: x = 1
    end type

    type :: pdt_parent(RKG)
        integer, kind :: RKG
        type(pdt_comp(RKG)) :: comp = pdt_comp(RKG)(real(1, RKG))
    end type

end module mod_pdt

program main

    use mod_pdt
    implicit none

    type(pdt_parent(RKG=RK)) :: a

end program main

If you click on the ... to open the second menu line and then </> you can enter code that is pretty printed.  Standard typed code is not easy to read.  

[Steve_Lionel]

Sorry, I'm going to pass on this one, other than to comment that gfortran historically has lots of issues with PDTs. I'd be more interested in what NAG Fortran has to say, but my license for that has expired. I don't spot an obvious problem with a cursory view.

[DataScientist]

@MarcGrodent 

@Steve_Lionel 
gfortran has a well-known bug for PDT component initialization:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104776

As far as I am aware, the GNU developers are actively working on a patch for this bug.

But this bug is completely irrelevant to PDT component initialization above, where "the component itself is a PDT". That is what IFX is complaining about.

I can confirm that the gfortran trunk with the relevant initialization patch accepts the syntax used in the example above and correctly assigns whatever initialization value appears for `x` in the component initialization of `pdt_parent`.
To me, this seems like a bug in IFX implementation of PDT.

[Steve_Lionel]

Well then, I hope someone at Intel picks up on it.