Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
公告
Important Update: Community Platform Migration​. Learn more​>
29649 讨论

Compiler bug using assumed rank when using pointers?

Paul_Levold
初学者
2,632 次查看

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 项奖励
1 解答
FortranFan
名誉分销商 III
2,603 次查看
@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 项奖励
3 回复数
Steve_Lionel
名誉分销商 III
2,606 次查看

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 项奖励
FortranFan
名誉分销商 III
2,604 次查看
@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 项奖励
Paul_Levold
初学者
2,582 次查看

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 项奖励
回复