Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

ALLOCATE with SOURCE curiosity

Ron_B
Novice
1,397 Views

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

 

12 Replies
Steve_Lionel
Honored Contributor III
1,388 Views

Test case, please.

0 Kudos
Ron_B
Novice
1,366 Views

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

 

Ron

0 Kudos
Ron_B
Novice
1,348 Views

Interestingly, error does not occur when I use IFORT

 

Ron

0 Kudos
andrew_4619
Honored Contributor III
1,336 Views

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
Honored Contributor III
1,260 Views

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

0 Kudos
IanH
Honored Contributor II
986 Views

@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.

0 Kudos
Ron_B
Novice
1,318 Views

Thanks!

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

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,250 Views

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. 

0 Kudos
Barbara_P_Intel
Employee
1,196 Views

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().

 

 

0 Kudos
Ron_B
Novice
1,155 Views

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

 

Ron

0 Kudos
Barbara_P_Intel
Employee
1,188 Views

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



flaxzune
Beginner
1,164 Views

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

0 Kudos
Reply