pure and const functions (__attribute__)

pure and const functions (__attribute__)


I'm struggling with failing unit tests that disappear if I remove the use of the const and pure attributes. Now, I'm certainly not able to guarantee that I'm using the attributes correctly everywhere, even though I thoroughly checked my uses of them. My main issue that I need answered first, though, is whether ICC is supposed to implement those attributes exactly as GCC documents them. Because I can't find documentation for the const and pure attributes in the ICC docs. If anyone knows that the pure and const implementation in ICC is flawed, I'd certainly like to know. Then I'd stop to bother and just #ifdef them out for ICC.

PS: If the ICC team would like to see lots of miscompilations from use of those attributes (I'm rather certain after a multidelta run) just check out my Vc package and compile the unit tests.

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


we have support of both attributes and problems are not known. It helps if you could provide a small reproducer to discuss.

Edit: As those are mostly beneficial for optimizations, do you also see the problems when optimization is completely turned off?

Best regards,

Georg Zitzlsberger

And once again the forum ate my post. :(

Alright. I take it that you mean that ICC follows what GCC documents. It would be nice to have such details documented in the ICC docs.

Yesterday I had multidelta reduce one miscompilation to 100 LOC, only to find the issue I reported about the __m128i and __m128 mismatch. So yes, I have a relatively small testcase, but it's not valid code anymore. I don't expect compilers to do the right thing if the code is broken. For this testcase I had to use -O1. Going lower made the issue disappear. AFAIU this problem requires some optimization steps to be present. I would assume that it requires common subexpression elimination.

Without reducing the testcase, it was already visible from the disassembly, that ICC generated code where data was loaded from the stack where nothing had been written before.

I will try to upload the testcase in a new post, before this text disappears too.

compile with 'icpc -O1 -xAVX'. If it outputs 'oasdifj' the compiler did it wrong. I reduced this testcase on a system with:

icpc (ICC) 13.0.0 20120731

Scientific Linux release 6.3

gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)


Downloadtext/x-c++src test3.cpp3.35 KB


thank you for the reproducer! I see the problem as well. Opposed to originally assumed that's not related to the attribute but rather seems to be a general optimization issue regarding dead code elimination. 12.1 compiler versions do not have this problem.
I've filed a defect ticket (DPD200318842) for engineering and will update this thread as I learn more. A workaround for such a general optimization issue cannot be provided, unfortunately.

Best regards,

Georg Zitzlsberger

Alright, thank you. Still, not using the const and pure attribute makes all my unit tests pass, whereas with the attribute I have lots of failures. So, they seem to trigger something in the optimizer that goes berserk...

>>...Because I can't find documentation for the const and pure attributes in the ICC docs...

By the way, MinGW C/C++ compiler v3.4.2 ( a GCC-like compiler for Windows / a little bit older version ) has a very good set of docs in a txt-format. If you're interested I could zip all doc files in a zip-archive and upload. Interested in that?


this problem will be fixed with Intel(R) Composer XE 2013 Update 3 that's available soon. The "pure" attribute indeed seemed to have caused problems visible at the dead code elimination stage.

Thank you for reporting & best regards,

Georg Zitzlsberger

Leave a Comment

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