Abstract Type/Array of Pointer/Types Strange Non-Reporting Error, Compiles but doesn't work

[kostas85]

Dear All,

Hello!  A few days ago I downloaded the latest ifort compiler. I've noticed a strange code behavior since the code compiles and runs but it doesn't report any error. After a bit of research I've reduced the code to the (probably) minimum line code that contains the problem(see attachment). I didn't have enough time to reduce the code further, so I'm sorry if it contains more than required.

A short description. I define four types:

1. An abstract type
2. Two "data holders": memberA , memberB
3. "Array of Pointers" references for the memberA and memberB
4. A type containing the references for memberA and memberB, called group

The expected code output is:

 Start
 working with
           1
           2
           3
           4
  -1.00000000000000       -1.00000000000000       -1.00000000000000     
   3.00000000000000     
 Done

The code compiles normally with 14.0.2 but doesn't give the expected result, instead in stops at :
 Start
 working with
           1

and does not report any error.

Compiling with -check all gives a segmentation fault. The code always compiles and works normally with 13.1.2. 

The following code changes result to a compiling and working code with 14.0.2:

• Change the module from group_defs_notworking to group_defs_working. The difference is that the type is not abstract
• Disable the list named nb defined at type "group"
• Use the module group_defs_notworking, in both module "new" and "i_test" subroutine

All of the above can be found as commented changes line in the code. Please let me know if you can reproduce the error or if you have any further comments. Thank you in advance.

Kostas

[FortranFan]

What happens if you run your program in a debugger and step through your code line by line?

[Steven_L_Intel1]

I can reproduce this and have escalated it to the developers as issue DPD200253978. The problem is that when calc goes to call reduce, it picks up a bogus address for the routine to call. Depending on what that address is, the symptoms can vary from a seg fault to just exiting.

Thanks for the nice test case and the workarounds you found. That will all be helpful in fixing the bug.

[kostas85]

Thanks, Steve! I look forward to having this back to normal, since both compilation and execution times seem to have been improved with 14.0.2 for my code.

Kostas

[Steven_L_Intel1]

I expect this problem to get fixed in Parallel Studio XE 2016 Update 3.