Valid specification expression is rejected by ifx 2025.1

[NCarlson]

Consider this example:

module foo

  type :: bar
    integer :: n
  end type

contains

  subroutine init(this, n)
    type(bar), intent(out) :: this
    integer, intent(in) :: n
    this%n = n
    block
      real :: array1(this%n)
    end block
    call sub
  contains
    subroutine sub
      real :: array2(this%n)
    end subroutine
  end subroutine

end module

ifx 2025.1 rejects this code with the following errors:

$ ifx -c intel-20250428.f90 
intel-20250428.f90(19): error #6582: A dummy argument which has the OPTIONAL or the INTENT(OUT) attribute is not allowed in this specification expression.   [THIS]
      real :: array2(this%n)
---------------------^
intel-20250428.f90(14): error #6582: A dummy argument which has the OPTIONAL or the INTENT(OUT) attribute is not allowed in this specification expression.   [THIS]
      real :: array1(this%n)
---------------------^
compilation aborted for intel-20250428.f90 (code 1)

This is incorrect.  In both cases, THIS%N is an object designator with base object (THIS)  that is made accessible by host association (2018: 10.1.11, par 2, item 4) and is thus a restricted expression and a valid specification expression.  The NAG compiler accepts this example.

[MarcGrodent]

Hello @NCarlson 

This compilation error is not specific to the ifx compiler. I get exactly the same one when your module is compiled with ifort (version included in oneapi 2023.2):

 

I think this is the expected behaviour as the dummy argument 'this' has the intent(out) attribute, so it cannot be used to specify an array bound. There is no compilation error when using the intent(inout) attribute.

  Marc

[NCarlson]

I understand where you're coming from (that's item 2 in the 10.1.11 list) and that's how I read it initially also. But a discussion on the fortran-lang discourse group clarified for me that the list of items in 10.1.11 is not an "and" list of constraints, but an "or" list. Further, THIS is a dummy argument only in the host scope of the block construct and internal subroutine,  and the latter access it via host association (that's item 4). I think that's clearly the case for the internal subroutine, but perhaps less so for the block.

[MarcGrodent]

Yes I understand your point. The strict application of the F2018 Interpretation Document should allow the declaration at line 19 as the THIS object is accessed by host association. Nevertheless it seems that the ifort and ifx compilers are stricter than required by the standard; the error message indicates that they still consider 'THIS' to be a dummy argument in subroutine 'sub' even though this is not strictly the case. I hope an Intel expert can clarify this issue...

[Steve_Lionel]

Intel Fortran has a long history of not properly supporting restricted expressions. I've reported issues with these multiple times over the years.

[Ron_Green]

I would agree with others that the code may be legal.  I can check with our Standards rep(s) to get a call.  To me it does look like ifort/ifx is incorrect.  I usually trust NAG for Standards related questions.

[Ron_Green]

I saw that John Reid said it's legal.  I will get a bug report opened for ifx to fix this.

[Ron_Green]

@NCarlson the ifx bug ID is CMPLRLLVM-67366.  Thanks for sending this to us.  I'll let you know when a fix for gets into a public release.