internal error: 04010003_1016

[Kar_Z_]

  15.0.1.148 windows version

when Qip is used, icl reports internal error: 04010003_1016

[Shenghong_G_Intel]

Hi Kar Z,

The test case passes with 15.0 initial release (looks like a regression issue?). I will try with same 15.0 Update 1 release version to confirm.

Thanks,

Shenghong

[Shenghong_G_Intel]

Hi Kar Z,

Sorry, I can reproduce it with both 15.0 initial release and update 1 version. It will only get that internal error with /Qip, not /Qipo, which is strange.

icl AvailableMemoryTracker.cpp -c /O2 -> works (Note: technically, this should use /Qip by default.)

icl AvailableMemoryTracker.cpp -c /Qip -> failed

icl AvailableMemoryTracker.cpp -c /Qipo -> works

icl AvailableMemoryTracker.cpp /Qip -> failed

icl AvailableMemoryTracker.cpp /Qipo -> failed (first warn with "Main entry point was not seen" and then failed...)

Looks like some crazy behavior when handling the command line options, as some of these options should be really same. I will look into more details and update you.

Thanks,

Shenghong

[Shenghong_G_Intel]

Hi Kar Z,

I've generated a small test case based on your big pre-processed file and file the issue to our problem tracking system. The crash is caused by optimizer (it works with O1, O2, O1+/Qip).

The internal tracking ID is: DPD200363325

Thanks,

Shenghong

[Kar_Z_]

shenghong-geng (Intel) wrote:

Hi Kar Z,

Sorry, I can reproduce it with both 15.0 initial release and update 1 version. It will only get that internal error with /Qip, not /Qipo, which is strange.

icl AvailableMemoryTracker.cpp -c /O2 -> works (Note: technically, this should use /Qip by default.)

icl AvailableMemoryTracker.cpp -c /Qip -> failed

icl AvailableMemoryTracker.cpp -c /Qipo -> works

icl AvailableMemoryTracker.cpp /Qip -> failed

icl AvailableMemoryTracker.cpp /Qipo -> failed (first warn with "Main entry point was not seen" and then failed...)

Looks like some crazy behavior when handling the command line options, as some of these options should be really same. I will look into more details and update you.

Thanks,

Shenghong

when useing Qipo, tthe error will appear during final library generation phase.

[Shenghong_G_Intel]

Hi Kar Z,

Thank you for the information, that makes more sense. If /Qip fail, /Qipo should also fail. :)

Also, to be noted, you can workaround by using O1 + /Qip as mentioned above. But in case you want to use O2 for most of the code and disable optimization for the code which caused the issue. You can add "#pragma intel optimization_level 0" for below functions (which will cause this internal error bug):

nsJemallocFreeDirtyPagesRunnable::AddRef

nsJemallocFreeDirtyPagesRunnable::Release

nsMemoryPressureWatcher::AddRef

nsMemoryPressureWatcher::Release

Adding the "pragma" before above 4 functions, your code can be build with: icl forum.cpp -c /Qip /O2

Hope it helps.

Thanks,

Shenghong

[Shenghong_G_Intel]

Hi Kar Z,

FYI, the issue is fixed in our mainline.

Thanks,

Shenghong

[Kar_Z_]

shenghong-geng (Intel) wrote:

Hi Kar Z,

FYI, the issue is fixed in our mainline.

Thanks,

Shenghong

When will it be available?

[Shenghong_G_Intel]

Hi Kar Z,

It should be in next update version as I see it is merged to 15.0 version mainline (I will also validate the fix with nightly build to double-check it)...

I do not have the information about the time frame of next update. But usually, we have an update version in about one quarter or even less. :)

Thanks,

Shenghong

[Kar_Z_]

shenghong-geng (Intel) wrote:

Hi Kar Z,

Thank you for the information, that makes more sense. If /Qip fail, /Qipo should also fail. :)

Also, to be noted, you can workaround by using O1 + /Qip as mentioned above. But in case you want to use O2 for most of the code and disable optimization for the code which caused the issue. You can add "#pragma intel optimization_level 0" for below functions (which will cause this internal error bug):

nsJemallocFreeDirtyPagesRunnable::AddRef

nsJemallocFreeDirtyPagesRunnable::Release

nsMemoryPressureWatcher::AddRef

nsMemoryPressureWatcher::Release

Adding the "pragma" before above 4 functions, your code can be build with: icl forum.cpp -c /Qip /O2

Hope it helps.

Thanks,

Shenghong

I failed to work around it. They are generated from complicate templates and defines.

And there are quite a lot of instances.

[Marián__VooDooMan__M]

FWIW in MSVC (and ICC is comaptible) if you need to put "#pragma" inside preprocessor define (macro), you need to use something like this:

#define MY_MACRO \
    __pragma(here_comes_your_pragma) \
    ...etc...

NB the doubled underscore.

[Marián__VooDooMan__M]

to be more clear:

#define MY_MACRO \
    __pragma(intel optimization_level 0) \
   ...etc...

[Shenghong_G_Intel]

Thank you Marian for providing the information about adding pragma in macros.

Kar Z,

Please check with Marian's suggestions and see whether you can figure it out. You may try to identify how these 4 functions are generated (which template and macros), and insert the macros into them. If you are unsure, you may post the code pieces here and we may discussion how to apply the pragms correctly. :)

Thanks,

Shenghong

[Kar_Z_]

shenghong-geng (Intel) wrote:

Thank you Marian for providing the information about adding pragma in macros.

Kar Z,

Please check with Marian's suggestions and see whether you can figure it out. You may try to identify how these 4 functions are generated (which template and macros), and insert the macros into them. If you are unsure, you may post the code pieces here and we may discussion how to apply the pragms correctly. :)

Thanks,

Shenghong

One exampple is " NS_IMPL_ISUPPORTS(nsMemoryPressureWatcher, nsIObserver)"

http://mxr.mozilla.org/mozilla-central/source/xpcom/base/AvailableMemoryTracker.cpp#439

[Shenghong_G_Intel]

Hi Kar Z,

Below is the example how to add the pragma in a macro (as Marian suggested):

__declspec(noreturn) void MOZ_NoReturn() {}

#define MY_ADDREF		\
__pragma(intel optimization_level 0)	\
void AddRef(int a) {	\
	if (a>10) {		\
		::MOZ_NoReturn(); 	\
	}	\
}

MY_ADDREF

Now, for your test case, it looks more complex, but in fact, it is similar. From the code you provided, NS_IMPL_ISUPPORTS is defined at:

http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsISupportsImpl.h#1043

#define NS_IMPL_ISUPPORTS(aClass, ...)                                        \
   NS_IMPL_ADDREF(aClass)                                                      \
   NS_IMPL_RELEASE(aClass)                                                     \
   NS_IMPL_QUERY_INTERFACE(aClass, __VA_ARGS__)

So, next step is to find the definition of “NS_IMPL_ADDREF” and "NS_IMPL_RELEASE", NS_IMPL_ADDREF below:

571 /**
572  * Use this macro to implement the AddRef method for a given <i>_class</i>
573  * @param _class The name of the class implementing the method
574  */
575 #define NS_IMPL_ADDREF(_class)                                                \
576 NS_IMETHODIMP_(MozExternalRefCountType) _class::AddRef(void)                  \
577 {                                                                             \
578   MOZ_ASSERT_TYPE_OK_FOR_REFCOUNTING(_class)                                  \
579   MOZ_ASSERT(int32_t(mRefCnt) >= 0, "illegal refcnt");                        \
580   if (!mRefCnt.isThreadSafe)                                                  \
581     NS_ASSERT_OWNINGTHREAD(_class);                                           \
582   nsrefcnt count = ++mRefCnt;                                                 \
583   NS_LOG_ADDREF(this, count, #_class, sizeof(*this));                         \
584   return count;                                                               \
585 }
586 

From here, we can see the _class::AddRef function, which will hit the internal error. So, to disable optimization for this function only, you can add below code (one line added "__pragma(intel optimization_level 0)"):

571 /**
572  * Use this macro to implement the AddRef method for a given <i>_class</i>
573  * @param _class The name of the class implementing the method
574  */
575 #define NS_IMPL_ADDREF(_class)                                                \
__pragma(intel optimization_level 0)  \
576 NS_IMETHODIMP_(MozExternalRefCountType) _class::AddRef(void)                  \
577 {                                                                             \
578   MOZ_ASSERT_TYPE_OK_FOR_REFCOUNTING(_class)                                  \
579   MOZ_ASSERT(int32_t(mRefCnt) >= 0, "illegal refcnt");                        \
580   if (!mRefCnt.isThreadSafe)                                                  \
581     NS_ASSERT_OWNINGTHREAD(_class);                                           \
582   nsrefcnt count = ++mRefCnt;                                                 \
583   NS_LOG_ADDREF(this, count, #_class, sizeof(*this));                         \
584   return count;                                                               \
585 }
586 

Do the same thing for "NS_IMPL_RELEASE", it is defined using "NS_IMPL_RELEASE_WITH_DESTROY", the code is very similar to AddRef, I am sure you know how to add the same pragma into it. :)

Thanks,

Shenghong

[Shenghong_G_Intel]

One more elegant way for the workaround (to only apply the workaround for this version of Intel Compiler, and you do not even need to change your code back for future update versions), please refer to below code:

__declspec(noreturn) void MOZ_NoReturn() {}

#if defined(__INTEL_COMPILER_BUILD_DATE) && __INTEL_COMPILER_BUILD_DATE == 20141023 // workaround for bug in ICC 15.0.1 (Update 1)
#define WORKARUOND_ICC_BUG_DPD200363325 __pragma(intel optimization_level 0)
#else
#define WORKARUOND_ICC_BUG_DPD200363325
#endif

#define MY_ADDREF		\
WORKARUOND_ICC_BUG_DPD200363325	\
void AddRef(int a) {	\
	if (a>10) {		\
		::MOZ_NoReturn(); 	\
	}	\
}

MY_ADDREF

Hope it helps.

Thanks,

Shenghong

[Kar_Z_]

shenghong-geng (Intel) wrote:

Thank you Marian for providing the information about adding pragma in macros.

Kar Z,

Please check with Marian's suggestions and see whether you can figure it out. You may try to identify how these 4 functions are generated (which template and macros), and insert the macros into them. If you are unsure, you may post the code pieces here and we may discussion how to apply the pragms correctly. :)

Thanks,

Shenghong

Finally, I removed the __declspec(noreturn) attribute, then the error is gone.

[Shenghong_G_Intel · Accepted solution]

Hi Kar Z,

yes, removing "noreturn" attribute can fix the error as it is the root cause of the issue. :)

But I am not sure whether removing it will have other side-effects, it may generate other warnings or errors, according to MSDN: http://msdn.microsoft.com/en-us/dynamics/k6ktzx3s.

Thanks,

Shenghong

[Shenghong_G_Intel]

Hi Kar Z,

FYI.

Intel compiler 15.0 update 2 (w_ccompxe_2015.2.179.exe) is released already, which contains the fix for this issue, I've verified that. You may upgrade and verify the fix.

Thanks,

Shenghong