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

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

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:

 working with
  -1.00000000000000       -1.00000000000000       -1.00000000000000     

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

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.


Downloadapplication/octet-stream whole.f903.87 KB
5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

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.

Steve - Intel Developer Support

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.


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

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today