status of C++11 "constexpr" support

[Marián__VooDooMan__M]

Greetings,

On other issue someone from Intel staff told they can't comment on Intel's future plans. This is indeed okay due to marketing, I guess.

On other issue someone from Intel staff told to fully implement C++11 is the fairly main goal of Intel.

But my question is, will "constexpr" be implemented in near future (i.e. ICC 13.x series) or will I need to wait for the long time (i.e. in ICC 14.x series maybe?)?

If you cannot comment on future plans even on my last rather abstract question, I will accept it. But I am so impatient, believe me. I guess I am not the only-one.

[TimP]

http://software.intel.com/en-us/articles/intel-composer-xe-2013-compilers-fixes-list

shows several related issues having been worked on.

14.0 beta test inception is overdue, so, if you have submitted a reproducer on functionality which isn't in 2013 update 3, it shouldn't be long before you could get a progress report.

[Marián__VooDooMan__M]

TimP (Intel) wrote:

http://software.intel.com/en-us/articles/intel-composer-xe-2013-compiler...

shows several related issues having been worked on.

14.0 beta test inception is overdue, so, if you have submitted a reproducer on functionality which isn't in 2013 update 3, it shouldn't be long before you could get a progress report.

Thank you very much for the URL I have not been aware of, and there are your internal tracking numbers which Intel staff is mentioning on this forum!

Thank you very much!

[Marián__VooDooMan__M]

My question is how ICC deals with "constant propagation optimization" optimization technique.

I just want to ask how ICC deals this kind of problem:

when in *.h file I have:

class foo { static const int ms_int; };

and in *.cpp file I have:

const int foo::ms_int=123;

this is old approach in C++99 standard.

1. I guess with optimization /Qip it will in other code/different *.cpp unit deference "ms_int" as it were global extern variable, so there is performance loss. Am I right?
2. Will in /Qipo the linker-generator code deal with it, and apply constant propagation of this kind of (as though it were) global extern variable, while considering of all *.obj files and it will decide, since it has const qualifier, it will propagate constant without assembler instruction getting value from address, but assembler instruction getting immediate argument (when it is possible), hence performance boost? Am I right?
3. But I guess, *.h code (NB: in *.h header file!):

class foo { constexpr int ms_int=123; };

even in /Qip mode (NB: NOT /Qipo !!!), the code will be much efficient, since compiler knows in advance the value of constant variable, so it can freely propagate constant. (thought contemporary ICC 13 doesn't support "constexpr").

Am I right in all 3 assuptions?

Since the bullet number [3] is future (since ICC currently does not support "constexpr"), I would like to know answer to bullet [1] and bullet [2] at least, but as for bullet number [3] I'd like to know the answer, though I feel my guess is right (since it was involved into C++11 standard exactly for this purpose (besides other uses of "constexpr")...).

[Mark_S_Intel1]

constexpr will be available in the 14.0 compiler.  The table at http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler shows the C++11 features the Intel C++ compiler supports today. The items labeled "partial" will be fully supported.

As for const propagation, the Intel compilers perform const propagation optimization at -O2, -Qip, -Qipo. 

--mark