Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner

This looks like a bug...

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
Highlighted
Black Belt

Nope, you're wrong. Go read

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner

Steve - the code works as

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
Highlighted
Black Belt

Yeah, it is a bug. Please

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

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Moderator

I wrote up a bug report. 

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
Highlighted
Valued Contributor III

Quote:Ronald W Green (Intel)

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
Highlighted
New Contributor II

For the example "INTEGER

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
Highlighted
Black Belt

Intent-ness and allocatable

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
Highlighted
Beginner

Thanks for filing the bug

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
Highlighted
Beginner

This may be a compiler bug.

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
Highlighted
Black Belt

Samuel, please start a new

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

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos