Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7956 Discussions

pure and const functions (__attribute__)

Matthias_Kretz
New Contributor I
526 Views

Hi,

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.

0 Kudos
7 Replies
Georg_Z_Intel
Employee
526 Views
Hello, 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
0 Kudos
Matthias_Kretz
New Contributor I
526 Views
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.
0 Kudos
Matthias_Kretz
New Contributor I
526 Views

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)

0 Kudos
Georg_Z_Intel
Employee
526 Views
Hello, 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
0 Kudos
Matthias_Kretz
New Contributor I
526 Views

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...

0 Kudos
SergeyKostrov
Valued Contributor II
526 Views
>>...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?
0 Kudos
Georg_Z_Intel
Employee
526 Views
Hello, 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
0 Kudos
Reply