Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28386 Discussions

Compiler bug using assumed rank when using pointers?

Paul_Levold
Beginner
1,086 Views

I'm trying to compile the following minimal example which combines assumed rank and pointers using Intel Fortran:

module mymod
    implicit none

    integer, target :: global_value = 1
    integer, target :: global_array_1d(2) = [1, 2]

contains

    subroutine set_pointer(ptr)
        integer, pointer, intent(out) :: ptr(..)

        select rank (ptr)
            rank (0)
                ptr => global_value
            rank (1)
                ptr => global_array_1d
        end select
    end subroutine
end module

program main
    use mymod
    implicit none

    integer, pointer :: value
    integer, pointer :: array_1d(:)

    call set_pointer(value)
    call set_pointer(array_1d)

    write(*,*) 'value: ', value
    write(*,*) 'value: ', array_1d

end program

 

Intel Fortran version 19.1.2.254 gives me the following errors:

main.f90(14): error #8201: Associate name cannot be a pointer.   [PTR]
                ptr => global_value
----------------^
main.f90(16): error #8201: Associate name cannot be a pointer.   [PTR]
                ptr => global_array_1d

  

GFortran version 10.2.0 does however compile without any errors.

I couldn't find anything in the documentation that indicates that this should be illegal, so I'm wondering if it is a compiler bug?

0 Kudos
1 Solution
FortranFan
Honored Contributor II
1,057 Views
@Paul_Levold wrote:

.. I'm wondering if it is a compiler bug?

 

@Paul_Levold ,

For whatever it's worth, I think it's a compiler bug also.  And if you're able to, I suggest you submit a support request at Intel OSC: https://supporttickets.intel.com/servicecenter?lang=en-US.

The 2 pointer assignments that are flagged as disallowed by the Intel compiler look conforming to me per the Fortran standard that states in section 11.1.10.3 Attributes of a SELECT RANK associate name and  p3, "The associating entity has the ALLOCATABLE, POINTER, or TARGET attribute if the selector has that attribute."

My hunch is some confusion may have inadvertently came about with the compiler developer(s) on account of how the standard collects the attributes of an associating entities in one section (11.1.3.3) where the entity is marked as NOT having the POINTER (and ALLOCATABLE, etc.) attributes of the selector e.g., in a SELECT TYPE construct.  But SELECT RANK is an exception to this as indicated in its own section.

Such a disjointed specification of aspects in a published standard on paper-only but little to no accompanying examples verified by "mental" compilers of standard writers are always likely to lead to errors in compiler implementations and I won't be surprised if that's what has led to the bug here.

View solution in original post

0 Kudos
3 Replies
Steve_Lionel
Honored Contributor III
1,060 Views

Yes, it is a bug. Please report it.

"The associating entity has the ALLOCATABLE, POINTER, or TARGET attribute if the selector has that
attribute. The other attributes of the associating entity are described in 11.1.3.3."

0 Kudos
FortranFan
Honored Contributor II
1,058 Views
@Paul_Levold wrote:

.. I'm wondering if it is a compiler bug?

 

@Paul_Levold ,

For whatever it's worth, I think it's a compiler bug also.  And if you're able to, I suggest you submit a support request at Intel OSC: https://supporttickets.intel.com/servicecenter?lang=en-US.

The 2 pointer assignments that are flagged as disallowed by the Intel compiler look conforming to me per the Fortran standard that states in section 11.1.10.3 Attributes of a SELECT RANK associate name and  p3, "The associating entity has the ALLOCATABLE, POINTER, or TARGET attribute if the selector has that attribute."

My hunch is some confusion may have inadvertently came about with the compiler developer(s) on account of how the standard collects the attributes of an associating entities in one section (11.1.3.3) where the entity is marked as NOT having the POINTER (and ALLOCATABLE, etc.) attributes of the selector e.g., in a SELECT TYPE construct.  But SELECT RANK is an exception to this as indicated in its own section.

Such a disjointed specification of aspects in a published standard on paper-only but little to no accompanying examples verified by "mental" compilers of standard writers are always likely to lead to errors in compiler implementations and I won't be surprised if that's what has led to the bug here.

0 Kudos
Paul_Levold
Beginner
1,036 Views

Thanks guys, and thanks for the link to report the bug, FortranFan. I tend to get a bit lost on the Intel webpages and I'm never quite sure where to report these things...

0 Kudos
Reply