Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

This looks like a bug...

OP1
New Contributor I
146 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
Black Belt Retired Employee
146 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.

OP1
New Contributor I
146 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).

Steve_Lionel
Black Belt Retired Employee
146 Views

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

Ron_Green
Moderator
146 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.

FortranFan
Honored Contributor II
146 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.

John_Campbell
New Contributor II
146 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.

IanH
Black Belt
146 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.

OP1
New Contributor I
146 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!

 

Key__Samuel
Beginner
146 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;

 

Steve_Lionel
Black Belt Retired Employee
146 Views

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

Reply