Assignment of an allocatable to an allocatable

[IanH]

When using the F2003 lhs (re)allocation of arrays in assignment feature (and /assume:realloc_lhs), can the left hand side array be not allocated prior to the assignment?

Under 11.0.061 with /check:all this blows up with an "attempt to fetch from ... not allocated" error, so maybe not?

[cpp]PROGRAM Allocation
  INTEGER, ALLOCATABLE :: starting(:)
  INTEGER, ALLOCATABLE :: finishing(:)
  INTEGER i  
  !*********
  ALLOCATE(starting(10))  
  !ALLOCATE(finishing(1))
  starting = [ (i, i = LBOUND(starting, 1), UBOUND(starting, 1)) ]
  finishing = starting
  WRITE(*,100) 'starting', starting
  WRITE(*,100) 'finishing', finishing
  WRITE(*,*) UBOUND(finishing)
  100 FORMAT(A20,1X,10(I4,1X,:))  
END PROGRAM Allocation
[/cpp]

If I uncomment the ALLOCATE(finishing(1)) statement it seems to work. But distinguishing between an array that is not allocated versus an array that is allocated to the wrong size seems a bit of a picky requirement for the feature.

The code above also seems to work if I make starting explicit shape (ie. INTEGER :: STARTING(10) and delete the relevant allocation statement), or if I put the finishing=starting assignment in a subroutine with the right hand side being an assumed shape argument, all of which confuses me as to what is legitimate and what is not.

Thanks,

IanH

[Steven_L_Intel1]

This is an error in the /check:pointer diagnostic test. If you turn that off, it works. I think we have another report of this already, but if not, I'll let the developers know.

[Steven_L_Intel1 · Accepted solution]

It turns out that the earlier issue I remembered was slightly diffrerent from this and is fixed in 11.0, but your test case is still broken. I have reported this to the developers and is our issue DPD200110210. The workaround is to not use /check:pointer and /assume:realloc_lhs together.

[IanH]

Quoting - Steve Lionel (Intel)

It turns out that the earlier issue I remembered was slightly diffrerent from this and is fixed in 11.0, but your test case is still broken. I have reported this to the developers and is our issue DPD200110210. The workaround is to not use /check:pointer and /assume:realloc_lhs together.

Thanks for the clarification.

[Steven_L_Intel1]

This problem will be fixed in a version to be released later this year.

[IanH]

It appears that the new 11.1 release (or maybe earlier) contained a fix for this. But while experimenting with the new (eagerly awaited, bye bye iso_varying_string...) deferred length character F2003 feature:

[cpp]PROGRAM DeferredLengthChar
  CHARACTER(LEN=:), ALLOCATABLE :: test  
  !****
  ! Should be automatically allocated to length of expression
  test = 'Hello there'  
  WRITE (*,100) test  
  100 FORMAT('"',A,'"')
END PROGRAM DeferredLengthChar[/cpp]

With /assume:realloc_lhs /check:all /warn:all I get a similar "Attempt to use pointer ..." error. If I take out the /check:all or put in a dummy ALLOCATE(CHARACTER(1)::test) statement then things "appear" to work, so I presume this is just the runtime diagnostic still playing up, rather than me exceeding the extent to which deferred length strings have been implemented?

[Steven_L_Intel1]

Yes - this is check:pointer not being informed of this new feature. Further, /assume:realloc_lhs ought not to be required in this case. I'll pass it on to the developers. Thanks. Issue IDs are DPD200137145 and DPD200137146.