topic I don't know if Issue in Intel® Fortran Compiler

Bad results from assignment to allocatable array (with realloc_lhs)

Neil_Carlson — Sun, 31 May 2015 22:25:33 GMT

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.

Thanks - I believe this is a

Steven_L_Intel1 — Mon, 01 Jun 2015 14:12:26 GMT

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.

I don't know if Issue

Neil_Carlson — Sat, 05 Sep 2015 17:32:46 GMT

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.

The internal id Steve

Kevin_D_Intel — Sun, 06 Sep 2015 08:47:11 GMT

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.

Thanks for the update Kevin,

Neil_Carlson — Sun, 06 Sep 2015 12:21:21 GMT

Thanks for the update Kevin, much appreciated.

The issue seems to have

Neil_Carlson — Mon, 14 Sep 2015 20:27:12 GMT

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.

Thank you for the update

Kevin_D_Intel — Tue, 15 Sep 2015 15:28:24 GMT

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.

I confirmed your issue is

Kevin_D_Intel — Wed, 11 Nov 2015 10:40:59 GMT

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