suggestion for error #6415: This name cannot be assigned this data type because it conflicts ...

[gauthier_108]

In a subroutine, I'm specifying the arguments dimensions based on parameters to the same subroutine:

module compiler_error_message_check
  use, intrinsic :: iso_c_binding
  implicit none
contains
  subroutine some_routine(array_1, array_1_count, array_2, array_3, array_2_and_3_count)
    real(kind=4)    , dimension(array_1_count)      , target, intent(inout) :: array_1
    character(len=8), dimension(array_2_and_3_count), target, intent(in)    :: array_2
    integer(kind=4) , dimension(array_2_and_3_count), target, intent(in)    :: array_3
    integer(kind=4) ,                                         intent(in)    :: array_1_count, array_2_and_3_count
    ! this leads to:
    ! This name cannot be assigned this data type because it conflicts with prior uses of the name.   [ARRAY_1_COUNT]
    ! This name cannot be assigned this data type because it conflicts with prior uses of the name.   [ARRAY_2_AND_3_COUNT]
    ! if I move the declaration before the array_1, it compiles
  end subroutine
end module

I was puzzled because the error message doesn't explain how to fix it, because in my case, the names aren't used anywhere (in module, or imported things).

If it makes sense, the error should specify where is the prior usage, and suggest that the definition needs to occur before and the two conflicting data types.

Somehow, it doesn't do this consistently (in another subroutine, it compiles fine, even when I define dimension parameter after using the name of it in a previous parameter declaration), but I'm not able to figure why and didn't come up with a self contained reproduce case where the message doesn't show.

Can someone confirm fortran code should have parameter be defined in a particular order when they are used to specify dimension of other declarations?

[jimdempseyatthecove]

I think this is a case of the compiler distinguishing between

integer :: I

and

integer(kind=4) :: J

Place implicit none in the interface and see what happens (when your integer(kind=4) declaration comes last)

Jim Dempsey

[gauthier_108]

@jimdempseyatthecove 

I started out of a module which has one interface section with 2 "extern C" subroutines defined, and in the "contains" section, two fortran routines with easier to use signatures (than passing pointers), calling the "extern C"

module my_module
  use, intrinsic :: iso_c_binding
  implicit none
interface
  subroutine f_1 () bind(C)
  end subroutine
contains
  subroutine f_1_easy_to_use_from_fortran
    !prepare arguments such as pointer to first item in arrays, etc.
    call f_1(...)
  end subroutine
end module

do you know if I need to put implicit none in any other place, because the error is also showing up despite I have the implicit none already just after the begin module declaration ?

[jimdempseyatthecove]

Your interface for f_1 has arguments defined as () - no arguments.

Yet, it the contained routine you are (presumably) passing arguments.

Please show the actual code and error messages.

Jim Dempsey

[IanH · Accepted solution]

F2023 10.1.11: "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association."

[gauthier_108]

@IanH, thanks for the fortran spec reference, this explains the error.

I think the error message could point that a declaration with same name is indeed occurring after, and need to reorder, or maybe doing a conformance warning in case the compiler is able to do the reordering of declarations.

Also, there is some context where I don't get the issue, but I might be chasing some "implicit integer a-z", I'll try to reproduce in a minimal case.

@jimdempseyatthecove, sorry I was giving short overview of the context I've hit the issue, I think the error is legit, per point in the spec @IanH mentions, but in some other code, I don't hit it so I was wondering why.

Thanks for your assistance.