- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Paul_Levold wrote:
.. I'm wondering if it is a compiler bug?
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Paul_Levold wrote:
.. I'm wondering if it is a compiler bug?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page