intel c++ 11.1.072 and gcc 4.5.0

[Alin_M_Elena]

I installed the intel c/c++ compilers on opensuse 11.3 m7updated to current factory...

unfortunately I got into this nasty bug

alin@felix:~> icpc -o a bug.cpp 
/usr/include/c++/4.5/iomanip(64): error: expected an expression
    { return { __mask }; }
             ^

/usr/include/c++/4.5/iomanip(94): error: expected an expression
    { return { __mask }; }
             ^

/usr/include/c++/4.5/iomanip(125): error: expected an expression
    { return { __base }; }
             ^

/usr/include/c++/4.5/iomanip(193): error: expected an expression
    { return { __n }; }
             ^

/usr/include/c++/4.5/iomanip(223): error: expected an expression
    { return { __n }; }
             ^

compilation aborted for bug.cpp (code 2)
here are the versions

alin@felix:~> icpc --version
icpc (ICC) 11.1 20100414
Copyright (C) 1985-2010 Intel Corporation.  All rights reserved.

alin@felix:~> g++ --version
g++ (SUSE Linux) 4.5.0 20100521 [gcc-4_5-branch revision 159657]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Alin

Please find the bug.cpp in theattachment.

[TimP]

For what it's worth, the headers in the opensuse 11.1 iomanip are like
inline _Resetiosflags
resetiosflags(ios_base::fmtflags __mask)
{
_Resetiosflags __x;
__x._M_mask = __mask;
return __x;
}
while the newer ones in my installation still define _Resetiosflags without using it:

inline _Resetiosflags
resetiosflags(ios_base::fmtflags __mask)
{ return { __mask }; }

so I guess the work-around for now would be to use from an earlier opensuse.

[Alin_M_Elena]

I am using 11.2 so I am notexperiencingin real life this bug... It came out in real life testing of 11.3...

Alin

[Feilong_H_Intel]

Hi Alin,

This is a known issue in our problem-tracking database. I'll let you know when I have an update regarding it.

Thank you.
--
Feilong H.
Intel Developer Support

Tools Knowledge Base: http://software.intel.com/en-us/articles/tools

[dacrim]

Has there been a resolution to this issue yet? We are also experiencing it and need to find a solution.

Regards,

Dave

[Feilong_H_Intel]

Hi Dave,

Our engineering team is still working on a fix for this issue. I'll keep you guys updated when I have an update.

Thanks,
Feilong

[Feilong_H_Intel]

Engineering team has implemented a fix for this in the next major version of the compiler. I'll let you know when the compiler that contains the fixis available for download.

Thanks,
Feilong

[jimdempseyatthecove]

There are two problem as I see it

1) return { __mask }; assumes a conversion operator will take place
try return ( _Resetiosflags ){ __mask }; or reinterpret...
or use the explicit conversion operator=() as tim18 illustrates
(note the optimizations will remove the __x and "fix" the bit field.

2) INTEL supportread this "fixing" the code to implicitly perform the conversion weakens the strong type checking of C++ and may break code relying on templates to disambiguate code expansions. In particular templates that use the hack of the enableif... to enable expansion as function.

By "fixing" this code example, may require the programmers to insert a plethora of "don't convert" functions/templates.

Jim Dempsey

[Markus_Hilt]

Maybe I have found a workaround for this special problem:

I've just installed the package 'libstdc++43-devel' which provides the include files of GCC 4.3 in the directory '/usr/include/c++/4.3'. If the environment variable GXX_INCLUDE points to this direcory the ICC uses the include files in this directory which solves the problem on my computer.

So, just add the following line to you .bashrc (or maybe to the iccvars.sh) and the icc should work...

export GXX_INCLUDE=/usr/include/c++/4.3

Best regards
Markus Hilt

[Thomas6]

Quoting Feilong H. (Intel)

Engineering team has implemented a fix for this in the next major version of the compiler. I'll let you know when the compiler that contains the fixis available for download.

Thanks,
Feilong

This bug is still present in the latest 11.1.073 compiler version. When will a final bugfix, i.e. a new major version, be available?

This is an annoying bug for all C++ developers using openSUSE systems. The Novell bugzilla entry https://bugzilla.novell.com/show_bug.cgi?id=610073 has been closed as the problem can only be solved by Intel.

Could the priority at Intel to finally fix this problem and get the fix out to all developers please be raised. Thanks.

[Feilong_H_Intel]

Thomas,

You are right. This issue won't be fixed in 11.1 compiler. The fix will be in 12.0 compiler.

Thanks,
Feilong

[Thomas6]

Quoting Feilong H. (Intel)

Thomas,

You are right. This issue won't be fixed in 11.1 compiler. The fix will be in 12.0 compiler.

Thanks,
Feilong

Thanks for the confirmation. Any rough idea when the 12.0 version might be available? I mean, are we talking about weeks, months, or even 2011... Any hints would be appreciated.

[TimP]

Intel 12.0 compiler release has been quoted on these forums as planned before end of year.
Maybe there will be a new round of catch-up, as gcc 4.6.0 should be in general use by then.

[graziano_giulianigma]

My personal fix on Arch Linux (4.5.1 g++), obviously on system header, is attached.

[TimP]

Quoting graziano.giulianigmail.com

My personal fix on Arch Linux (4.5.1 g++), obviously on system header, is attached.

It looks like you've simply copied an earlier version of the header which may have been tested with current icpc (the same suggestion made early in this thread). I suppose this risks breaking the new g++.

[graziano_giulianigma]

No, it does not break g++, it does only use "old" version of header for icpc using the INTEL_COMPILER macro defined by icpc and not by g++ to decide which one to use.

[Markus_Hilt]

Intel compiler suite 12.0 is now available (now called the Intel Composer XE). However, as far I can see the problem has NOT been fixed. When I use Intel Compiler 12.0.0.084 (Intel C Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.0.084 Build 20101006) I still get the following error messages:

/usr/include/c++/4.5/iomanip(64): error: expected an expression
{ return { __mask }; }
^

/usr/include/c++/4.5/iomanip(94): error: expected an expression
{ return { __mask }; }
^

/usr/include/c++/4.5/iomanip(125): error: expected an expression
{ return { __base }; }
^

/usr/include/c++/4.5/iomanip(193): error: expected an expression
{ return { __n }; }
^

when I try to compile this little piece of code

[cpp]#include
#include

using namespace std;

int main()
{
 cout<<"hello icc"< 

I am using OpenSUSE Linux 11.3 and gcc 4.5 (gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]).

Best regards
 Markus

[qtl]

I am using g++ 4.5.1 and the new icpc 12,
/usr/include/c++/4.5.1/iomanip(64): error: expected an expression
{ return { __mask }; }
^

/usr/include/c++/4.5.1/iomanip(94): error: expected an expression
{ return { __mask }; }
^

/usr/include/c++/4.5.1/iomanip(125): error: expected an expression
{ return { __base }; }
^

/usr/include/c++/4.5.1/iomanip(193): error: expected an expression
{ return { __n }; }
^

/usr/include/c++/4.5.1/iomanip(223): error: expected an expression
{ return { __n }; }
^

compilation aborted for tst.cpp (code 2)

[TimP]

Yes, I see the same, running on Red Hat 6. If I set PATH temporarily to the Red Hat g++ 4.4.4, no problem, but with the g++ 4.5.1 downloaded from gfortran wiki, same errors as reported above.

[stevenpclark]

This problem is biting me as well. I see it both in 11.1 and in 12.0.

Really annoying!!!

[rda]

Try adding this compiler flag to "fix" it: -std=c++0x

In 4.5, gcc is starting to use some c++0x syntax (specifically "initializer lists" - see http://en.wikipedia.org/wiki/C%2B%2B0x#Initializer_lists ). In gcc, there's a magic pragma "#pragma GCC system_header" that apparently permits c++0x constructs in gcc header files without explicitly enabling c++0x support. Try this in a .cc file, it fails without the extra -std flag. Put it in an include file, it also fails. Add the magic pragma (to the include file) and it's accepted and succeeds.

Intel could try to mimic the behavoir of "#pragma GCC system_header", which would make this issue go away.