- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- An abstract type
- Two "data holders": memberA , memberB
- "Array of Pointers" references for the memberA and memberB
- 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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What happens if you run your program in a debugger and step through your code line by line?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I expect this problem to get fixed in Parallel Studio XE 2016 Update 3.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page