ALLOCATE with SOURCE curiosity

[Ron_B]

I have a derived type with an allocatable integer array component.

I have a procedure for initialization that checks and deallocates it, and then will allocate it with a default set of values.

if(allocated(this%wt_sums)) deallocate(this%wt_sums)

allocate(this%wt_sums, source=def_wt_sums)

def_wt_sums is also an allocatable integer array that is initialized upon program execution.

The curiosity happens in that the first time this is executed, it performs correctly.  However, the second time it is called, it fails returning the error message

"forrtl: severe (408): fort: (10): Subscript #1 of the array WT_SUMS has value 140698534922351 which is greater than the upper bound of 14"

 (The value is random, so I'm assuming it's a memory address.)

The bounds of wt_sums are correct, but it appears the source clause is not executing correctly.  Is the difficulty due to using an allocatable array as the source? It works correctly if I use:

allocate(this%wt_sums,mold=def_wt_sums)

this%wt_sums = def_wt_sums

I am using IFX, Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.0.2 Build 20231213

Ron

[Steve_Lionel]

Test case, please.

[Ron_B]

Removed the other 200,000+ lines, but the error remains.

Ron

[Ron_B]

Interestingly, error does not occur when I use IFORT

Ron

[andrew_4619]

you also get an error with IFX 2024.1.0 , seems like a bug to me. The allocate at line 6 below gives an error the second time around.

  subroutine t_wtgrouping_init(this)
    class(T_WTGROUPING), intent(inout) :: this
    this%id      = 0
    this%descrip = ''
    !if (allocated(this%wt_sums)) deallocate(this%wt_sums)
    !allocate(this%wt_sums,source=def_wt_sums)
    this%wt_sums = def_wt_sums ! works with realloc
  end subroutine t_wtgrouping_init

Why not use that lovely feature of realloc LHS and save typing that works.  Those good kind Fortran committee people gave is this feature.

[jimdempseyatthecove]

>>Why not use that lovely feature of realloc LHS

While it works, it works more often than necessary. Old code that had/has

ArrayOut = (Array Expression)

Would (maybe not now) invariably realloc the LHS even though the expression had the same rank and sizes.

Jim Dempsey

[IanH]

---

@jimdempseyatthecove wrote:

>>Why not use that lovely feature of realloc LHS

While it works, it works more often than necessary. Old code that had/has

ArrayOut = (Array Expression)

Would (maybe not now) invariably realloc the LHS even though the expression had the same rank and sizes.

---

Fear not - a compiler that did such reallocation would be broken. 

Reallocation of the LHS is not permitted by the rules of the language if the shape (and dynamic type) matches.

[Ron_B]

Thanks!

Aero engineer that has been self-taught Fortran over the years loves discovering things like this.

[Steve_Lionel]

I sure hope it doesn't reallocate now when it shouldn't - one of the last things I did before I retired was write a new run-time routine to handle this operation. 

[Barbara_P_Intel]

Interesting that you only get the traceback when you compile with /check:bounds. Or in my case on Linux "-check bounds".

And, yes, it occurs with the second call to wr_grp%init().

[Ron_B]

It appears the bug is with the check array bounds.  If I turn the check off, it performs correctly without a traceback.

Ron

[Barbara_P_Intel]

I filed a bug report for this, CMPLRLLVM-57391. Stay tuned for an update.

[flaxzune]

Interesting that you only get the traceback when you compile with /check:bounds. Or in my case on Linux "-check bounds".