Getting error #6410: This name has not been declared as an array or a function. [SIZE]

[LFL1]

Hello,

Using the attached code (summary_deallocate_struct.f90), I'm getting the following error when compiling:

$ ifort -c -module ifort  -Iifort summary_deallocate_struct.f90 -o summary_deallocate_struct_ifort.o


summary_deallocate_struct.f90(455): error #6410: This name has not been declared as an array or a function. [SIZE]
do i = 1,size(struct_in2%divertor_plate)
-------------^
summary_deallocate_struct.f90(463): error #6410: This name has not been declared as an array or a function. [SIZE]
do i = 1,size(struct_in2%divertor_target)
-------------^

If I remove the following functions from the interface (and also the implementations at the end of the file)  'ids_deallocate_struct':

module procedure ids_deallocate_struct_summary_rmp
module procedure ids_deallocate_struct_summary_runaway115
module procedure ids_deallocate_struct_summary_sol
module procedure ids_deallocate_struct_summary_wall
module procedure ids_deallocate_struct_summary_limiter

It compiles fine when removing these functions.

So, what's going on here? Why am I getting an error on the use of the 'size' intrinseque function?

Why the issue is fixed if I remove the routines indicated above? Could it be that the issue is related to the length of the source file (summary_deallocate_struct.f90) ?

I'm using the following ifort compiler:

$ ifort --version
ifort (IFORT) 19.1.3.304 20200925
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

Thanks a lot for your help.

[jimdempseyatthecove · Accepted solution]

Not seeing the contents of your modules, my guess is one of your modules has a scalar variable named "size".

To correct for this, add ", only: WhatIsNeededHere, OtherItemsHere, ..." to the appropriate use YourModuleHere.

IOW omit the scalar "size"

Jim Dempsey

[LFL1]

I could find indeed a field named 'size' in some source files from the 'ids_schema' module. I could not test for some reason, however I'm already convinced it was the issue.
Thanks a lot!

[FortranFan]

@LFL1 

You may know the solutions provided by the Fortran standard which may help you also INCLUDE:

1. rename of a module entity in a USE scope e.g. "use ids_schemas, xx=> size" where `xx` is some local entity per the programmer of that scope, say ids_schemas_size.  Meaning the `ONLY` keyword is not necessary unless that is of interest.
2. apply the `INTRINSIC` attribute in the scope where there can be a name collision

Here is a silly example:

module ids_schemas
   integer :: size = 100
   integer :: foo = 42
end module
   use ids_schemas, ids_schemas_size => size !<-- note the renaming
   type :: t
      integer :: n(2)
   end type
   call sub()
   print *, "main: size = ", ids_schemas_size, "; expected is 100"
   print *, "main: foo = ", foo, "; expected is 42"
   call sub()
contains
   subroutine sub()
      type(t) :: x
      integer :: i
      intrinsic :: size  !<-- note the intrinsic attribute
      do i = 1, size(x%n)
         x%n(i) = i
      end do
      print *, "in sub: x%n = ", x%n
   end subroutine 
end

C:\temp>ifort /free /standard-semantics p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
 in sub: x%n =  1 2
 main: size =  100 ; expected is 100
 main: foo =  42 ; expected is 42
 in sub: x%n =  1 2

[LFL1]

Hello @FortranFan 

These are quite convenient solutions indeed. I'm ready to use the first one. However, I will have a look on the 'intrinsic' attribute.

Thanks a lot!