- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consider the following minimal example:
integer,allocatable::a(:),b(:,:)
allocate(a(20000000))
allocate(b(2,size(a)/2))
b=reshape(a,shape(b))
endThe executable compiled with ifx 2025.2.0, ends with a segmentation fault in the line with `reshape`. It can be avoided by either:
- compiling with `-heap-arrays`,
- reducing the size of `a`, or
- explicitly specifying the shape in `reshape`, i.e. `[2,size(a)/2]` instead of `shape(b)`.
Considering that `-heap-arrays` fixes this problem, I assume, it's stack overflow. However, I don't understand, why it's happening in `reshape`, and why explicit shape fixes this problem. Is it a bug?
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've tested the code on Windows 11 with 3 compilers:
- ifort (2021.10.0): stack overflow at line #4
- ifx (2025.3.0): same stack overflow at line #4
- gfortran (14.2): no problem
To me this is a bug. The call to the 'shape' function returns a huge temporary array that is stored on the stack triggering the overflow. As you pointed out, there is no problem if an array constructor is used for the shape argument (perhaps in this case the array is stored directly on the heap ...?).
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page