This looks like a bug...

[OP1]

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

[Steve_Lionel]

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]

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]

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

[Ron_Green]

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]

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]

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]

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]

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]

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]

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