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

Many ICEs with IVF12

Paul_Curtis
Valued Contributor I
944 Views
The new version 12 has a number of C000005 errors, on code that compiled/linked perfectly under the last version (11.1.074)... should I wait, send the project to Premier Support??

This error msg unfortunately precludes abstracting whatever code feature causes the error.
0 Kudos
5 Replies
Steven_L_Intel1
Employee
944 Views
Oh dear. Yes, please send us the project via Premier Support - we'll take it from there.
0 Kudos
jirina
New Contributor I
944 Views
I'd like to report that I am having the same problem - ICE (code C0000005) with no information which part of the source file is causing the error - the output shows the name of the file followed by "(code 1)". I will try sending the corresponding files to Premier Support if that might help; I'd only like to make sure they are treated as confidential. The code compiles well with IVF 11.1.067. Thank you in advance.

Edit: I have just submitted two issues, both ICE, one when compiling for IA-32 platform, the other one for Intel 64 platform; corresponding source code files were uploaded too. The two ICEs occur when compiling a different source file.
0 Kudos
Steven_L_Intel1
Employee
944 Views
Thanks for the submissions. Intel Premier Support is a secure channel and we keep your code private.
0 Kudos
Paul_Curtis
Valued Contributor I
944 Views
No response yet from Premier Support, but I have found exactly what causes v12 to crash, at least for my code: using LOC(something) as an argument to a function or subroutine. Here is an example of what used to work, now fails:

[bash]! Interfaces to Microsoft Visual C library thread routines
! Must link against multithreaded libraries
interface
  function $beginthreadex (security, stack_size, start_address, arglist, &
						   initflag, thrdaddr)
  use ifwinty
  integer(UINT) :: $beginthreadex
  !DEC$ ATTRIBUTES C, alias:"__beginthreadex" :: $beginthreadex
  type(T_SECURITY_DESCRIPTOR), intent(IN) :: security
  !DEC$ ATTRIBUTES REFERENCE, ALLOW_NULL :: security
  integer(UINT),  intent(IN) :: stack_size
  integer(PVOID), intent(IN) :: start_address  ! Must be STDCALL calling
											   ! mechanism, 1 arg
  integer(PVOID), intent(IN) :: arglist
  integer(UINT),  intent(IN) :: initflag
  integer(UINT),  intent(OUT):: thrdaddr
  !DEC$ ATTRIBUTES REFERENCE,IGNORE_LOC :: thrdaddr
  end function $beginthreadex
end interface   


!   sample code; this worked perfectly up through v11.1.074,
!   causes a C000005(code1) error in v12 (error disappears if commented out)

threads(i)%handle =		&
    $beginthreadex (NULL,					& ! security descriptor
			        0,						& ! initial stack size
			        LOC(BackupThreadProc),  & ! ptr to thread function
			        LOC(threads(i)%args),	& ! ptr to threadsafe data 
			        0,						& ! creation flag -- start immediately
			        threadId)                 ! returned thread identifier; was LOC()
[/bash]


Any help/workaround suggestions would be greatly appreciated.
0 Kudos
kferrio
Beginner
944 Views
We'vealso reported two ICEs via Premier Support, with very specific, minimal test cases. Both were reprodcued by Intel well within 24 hours. One is a C0000005 and the other is not. Neither involves a LOC. So it seems the team has plenty of work to do, and they seem to be taking it very seriously based on my interactions with them. I don't want to downplay these issues, but these are the only two ICEs I've expereinced in several hundred thousand lines of regression testing code so far. I'm optimistic for timely resolutions given the excellent communication taking place.
0 Kudos
Reply