- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Test case, please.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interestingly, error does not occur when I use IFORT
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!
Aero engineer that has been self-taught Fortran over the years loves discovering things like this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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().
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It appears the bug is with the check array bounds. If I turn the check off, it performs correctly without a traceback.
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I filed a bug report for this, CMPLRLLVM-57391. Stay tuned for an update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting that you only get the traceback when you compile with /check:bounds. Or in my case on Linux "-check bounds".
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page