- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've attached a small example that clearly demonstrates that bad results are obtained from assignment to an (unallocated) allocatable array. I am using the required realloc_lhs switch. The problem exists with both Intel 14.0.3 and 15.0.2. A key ingredient to the problem seems to be that the rhs of the assignment is an elemental type bound function referenced through a derived type array.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks - I believe this is a problem we're already looking at, issue ID DPD200362026. The other case involves use of an elemental function call in an ALLOCATE with SOURCE=, but the behavior is the same, as is the fact that it worked in 13.1 but not in 14.0. I'll let you know what we find.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Was DPD200362026 fixed for 16.0? If so there is still a problem. My attached reproducer is still failing for this new version. The only difference is that it now results in a segfault instead of garbage results. The good news is that 16.0 resolves all my other outstanding bug reports (8 in all), the oldest going back to Oct 2012.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The internal id Steve associated with your issue has not been fixed in the 16.0 release. He believed it was related to this report (https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/532723).
I tested your case and the other case and found that nether is fixed in the 16.0 release. I confirmed the segmentation-fault you noted about your test case. I also found that both cases produce expected results with our latest internal development 16.0 compiler. So, it appears Development may have a fix in the pipeline for these two cases. I will update the internal tracking id with these latest findings and we will keep you posted regarding new status as we learn it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the update Kevin, much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue seems to have gotten "worse" with the 16 compiler. In my attached example the lhs allocatable array needed to be allocated as part of the assignment
sizes = sets%size()
The workaround I cited (commented-out code) was to allocate the lhs array and then assign to it. This worked with the 15.0.3 compiler, but does not with the 16.0 compiler. Even in that case the lhs array is filled with bad data. I suppose the new workaround is to use a do-loop and make the assignment element-by-element. Just wanted to let you know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the update regarding this change in the work around, that is unfortunate.
With regard to the fix for the earlier cited internal id, Development confirmed the issue is fixed as I noted earlier it appeared to be and that the fix will be in the next 2016 Update 1 tentatively targeted for early November.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirmed your issue is fixed in our upcoming Parallel Studio XE 2016 Update 1 release which should be available soon.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page