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

Bad results from assignment to allocatable array (with realloc_lhs)

Neil_Carlson
Beginner
594 Views

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.

0 Kudos
7 Replies
Steven_L_Intel1
Employee
594 Views

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.

0 Kudos
Neil_Carlson
Beginner
594 Views

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.

0 Kudos
Kevin_D_Intel
Employee
594 Views

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.

0 Kudos
Neil_Carlson
Beginner
594 Views

Thanks for the update Kevin, much appreciated.

0 Kudos
Neil_Carlson
Beginner
594 Views

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.

0 Kudos
Kevin_D_Intel
Employee
594 Views

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.

0 Kudos
Kevin_D_Intel
Employee
594 Views

I confirmed your issue is fixed in our upcoming Parallel Studio XE 2016 Update 1 release which should be available soon.

0 Kudos
Reply