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

This looks like a bug...

OP1
New Contributor III
951 Views

I believe the output of the following code should be -2, 0 instead of 1, 1. But I may be wrong too... the code is built with 19 Update 2.

PROGRAM P
IMPLICIT NONE
INTEGER,ALLOCATABLE :: I(:,:)
ALLOCATE(I(-2:3,0:4))
CALL S(I)
CONTAINS
    SUBROUTINE S(V)
    INTEGER,INTENT(IN),ALLOCATABLE :: V(..)
    WRITE(*,*) LBOUND(V)
    END SUBROUTINE S
END PROGRAM P

 

0 Kudos
10 Replies
Steve_Lionel
Honored Contributor III
951 Views

I'm not sure this is a bug. Certainly if the dummy wasn't POINTER or ALLOCATABLE, 1 would be the right answer. I know that for POINTER dummies, the actual lower bound should come through. Maybe ALLOCATABLE too. Let me ask some people.

0 Kudos
OP1
New Contributor III
951 Views

Steve - the code works as intended if the dummy argument V is declared as INTEGER,INTENT(IN),ALLOCATABLE :: V(:,:) . In the example above it is declared as an assumed rank variable V(..) (although deferred rank is probably the better wording here, since V is declared as allocatable).

0 Kudos
Steve_Lionel
Honored Contributor III
951 Views

Yeah, it is a bug. Please report it to Intel at the Online Service Center.

0 Kudos
Ron_Green
Moderator
951 Views

I wrote up a bug report.  Interestingly we had this working in the v16 compilers, v17 and the initial 18.0.0.  It broke in compiler v18 Update 1 and newer (regression).

Thanks for bringing this to our attention.

0 Kudos
FortranFan
Honored Contributor III
951 Views

Ronald W Green (Intel) wrote:

I wrote up a bug report.  Interestingly we had this working in the v16 compilers, v17 and the initial 18.0.0.  It broke in compiler v18 Update 1 and newer (regression).

Thanks for bringing this to our attention.

@Ronald W Green (Intel),

Thank you very much for your feedback, such input from Intel team is most valuable.

0 Kudos
John_Campbell
New Contributor II
951 Views

For the example "INTEGER,INTENT(IN),ALLOCATABLE :: V(..)" can you have both INTEGER,INTENT(IN) and ALLOCATABLE ?

I would have thought they are mutually exclusive, or at least ALLOCATABLE could be ignored.

0 Kudos
IanH
Honored Contributor III
951 Views

Intent-ness and allocatable-ness are orthogonal concepts, not mutually exclusive concepts.

An INTENT(IN), ALLOCATABLE object can have its allocation status (or value, if it is allocated) queried, but it cannot have its allocation status (or value, if it is allocated) modifed.

In some ways it is a bit like an INTENT(IN), OPTIONAL dummy, practically more so in recent standards.

0 Kudos
OP1
New Contributor III
951 Views

Thanks for filing the bug report (I had filed one too). Having access to the exact bounds of deferred-shape allocatable arrays (whether assumed-rank or not) is the reason of the ALLOCATABLE,INTENT(IN) declaration.

Honestly, I can't wait until SELECT RANK is implemented - this will save A LOT of tedious and repetitive work!

 

0 Kudos
Key__Samuel
Beginner
951 Views

This may be a compiler bug. It is a big change in results from FORTRAN V18 to V19. (I am willing to explore this behavior further if someone will tell me what to do to narrow it down.)

Added information 2/26/2019:

I have tried different optimization settings and this is the result:

(6) Optimization -O1 produces correct numerical results;
     Optimization -O2 produces bad     numerical results;
     Optimization -O3 produces bad     numerical results;

 

0 Kudos
Steve_Lionel
Honored Contributor III
951 Views

Samuel, please start a new thread for your different issue, and be sure to attach a minimal, reproducible test case.

0 Kudos
Reply