Error with initialization in parameterized derived type (PDT)

[ivanpribec]

I am facing an error when initializing a component of a PDT. If I initialize the c_ptr component of my derived type to c_null_ptr, I get an error when an instantiate an instance of my PDT. If the initialization expression is omitted the code compiles successfully.

Is this behavior expected?

I am using the Intel Fortran Compiler on Linux. The exact version, minimal working example and compiler output are shown below.

$ ifort --version
ifort (IFORT) 19.1.0.166 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

$ cat nanoflann_ResultSets_stripped.f90 
module nanoflann_ResultSets
  
  use iso_c_binding

  implicit none

  integer, parameter :: dp = kind(1.0d0)

  type :: KNNResultSet(prec)
    integer, kind :: prec
    type(c_ptr) :: ptr = c_null_ptr ! This line leads to the error indicated below
    ! type(c_ptr) :: ptr            ! If not initialized, the example compiles succesfully.  
    integer(c_int) :: capacity_
  end type

contains

  function new_KNNResultSet(capacity) result(this)
    integer(c_int), intent(in) :: capacity
    type(KNNResultSet(dp)) :: this  ! If this%ptr is default initialized, I get error #6973 on this line.
    this%capacity_ = capacity
  end function

end module
$ ifort -warn all nanoflann_ResultSets_stripped.f90 -c
nanoflann_ResultSets_stripped.f90(20): error #6973: This is not a valid initialization expression.
    type(KNNResultSet(dp)) :: this  ! If this%ptr is default initialized, I get error #6973 on this line.
^
compilation aborted for nanoflann_ResultSets_stripped.f90 (code 1)

[ivanpribec]

The thread linked below had a similar error related to initialization:

https://community.intel.com/t5/Intel-Fortran-Compiler/Compiler-Bug-parameterized-derived-type-omitted-field-in/m-p/1136317#M135832

[FortranFan · Accepted solution]

@ivanpribec ,

It's clearly a bug in the compiler version you're trying.

Is it possible for you to try the code you're working with using IFORT in Intel oneAPI i.e., v2020.1?  Your simple reproducer compiles ok with oneAPI IFORT version.

By the way, I had submitted a flurry of support requests at Intel OSC earlier toward PDT feature implementation in IFORT including many, many incident submissions that I made post v18.0.5 compiler update.  The requests included many ICEs but also other bugs relative to the Fortran standard.  Post 19.1, I find Intel has made many enhancements to PDT feature and they have all made it to oneAPI IFORT from what I see given my Intel OSC incident requests.  So I suggest proceeding with oneAPI IFORT, if you're able to.

[ivanpribec]

Thanks @FortranFan.

So far I have not installed the oneAPI compilers. I expect my previous ifort academic license (valid for 1-year) should run out soon. I will probably upgrade at that point.

Sorry for the opportunism, do you know if the Fortran and C Intel oneAPI compilers play well together? The code I am developing is interfacing with a code in C++. I was surprised to find learn the icpc compiler "borrows" the front-end from the gnu compiler collection. With version 19.1 of icpc and ifort, I had to use the flag -gxx-name=g++-8 to compile my project.

[Barbara_P_Intel]

In oneAPI, icc/icpc and ifort are the next major releases after 19.1 that was available in PSXE 2020.  You can expect new functionality and bugs fixes. Whatever hoops you jumped through to compile and link before remain.

[JohnNichols]

The main difference is the location and name of the batch files to set the environment variables and path. 

And the directory name has been changed from intelsw to intel 

Fileseek is a good program to find the batch files - search for setvars.bat

You need to run this after the base and the HPC install although the HPC notes do not tell you to do this for some reasons. 

Also the VS 2019 file list - uses Visual Fortran as the standard name and not Intel Fortran. This is likely a vsix error.