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.
This error msg unfortunately precludes abstracting whatever code feature causes the error.
链接已复制
5 回复数
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.
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.
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:
Any help/workaround suggestions would be greatly appreciated.
[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.
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.
