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.

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

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

Regards,

Dave

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

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

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

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

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.

Thomas,

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

Thanks,
Feilong

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.

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.

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

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.

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

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

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)

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.

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

Really annoying!!!

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.

RDA-
Thanks for the suggestion. Unfortunately, (with 11.1 at least) adding that flag just results in a DIFFERENT compilation error:

BEFORE:
/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 }; }

AFTER:
/usr/include/c++/4.5.1/bits/stringfwd.h(74): error: identifier "char16_t" is undefined
template<> struct char_traits;
^

/usr/include/c++/4.5.1/bits/stringfwd.h(75): error: identifier "char32_t" is undefined
template<> struct char_traits;
^
[....many more similar errors....]

/usr/include/c++/4.5.1/type_traits(106): error: expected a ">"
struct remove_reference<_Tp&&>
^

/usr/include/c++/4.5.1/type_traits(136): catastrophic error: rvalue references not yet implemented
{ typedef _Tp&& type; };
^

compilation aborted for test.cc (code 4)

Do I need to bump back up to 12.0 for that compiler flag to work?

Thanks
-Steven

I did check that the case is accepted by icpc 12.0 under -std=c++0x
That option is better implemented in 12.0.

Will 12.0 be available anytime soon? The new naming on the web site doesn't make it clear what version is available now. However, section 3.6.4 "TR1 System Headers" seems to imply that the current release is still an 11.X version which does not fix this issue.

Is it possible to get a beta version of 12.0?

xe 2011 is the marketing name for the 12.0 compilers. The beta licenses have expired; if you are still within the active term of your license, you can download the new compiler.

With version 12.0.2 20110112 compiling with -std=c++0x still gives the same problem, but the workaround to use CPPFLAGS += -std=c++0x still works.

I am evaluating icc version 12.0.2, and this problem persists on openSUSE 11.3 (x86_64)
VERSION = 11.3.

Is there a fix, or sould one use a old iomanip.h file localy?

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 }; }

Thanks!

Thanks a lot, rda, That worked perfectly for me!!

By the way, do you know how can I include the -std=c+0x flag in a makefile? I've tried "CXXFLAGS = -std=c++0x", but it doesn't work..

Thanks in advance

That would be a normal way, if $(CXXFLAGS) is included explicitly in the rules for making .o files from C++ sources. If the Makefile uses ($CXXFLAGS), you would be adding the option to those already set. This surely depends on how the Makefile is set up.
If you wish the flag to be always set for icpc, you can include it in icpc.cfg in your compiler installation.

Thank you TimP. I'm sorry because I'm a newbie and still don't know very well how to do it. I wrote this in the makefile:

CPPOPTIONS = -I$(NETCDF)/include
CXX = icpc
CXXOPTIONS = -o3
CXXFLAGS = -std=c++0x
DEBUG =-g -D DEBUG

$(CXX):$(CXXFLAGS)$(CXXOPTIONS)$(DEBUG)-c $*.cpp
$(MAKE)$(MAKEFILE)DEBUG="-g -D DEBUG"

and I got this error:

make: *** No rule to make target `-std=c++0x-o3', needed by `icpc'. Stop.

So, as you said, I need to specify it somewhat in the rules...

CPPOPTIONS = -I$(NETCDF)/include
CXX = icpc
CXXOPTIONS = -o3
CXXFLAGS = -std=c++0x
DEBUG =-g -D DEBUG

$(CXX):$(CXXFLAGS)$(CXXOPTIONS)$(DEBUG)-c $*.cpp
$(MAKE)$(MAKEFILE)DEBUG="-g -D DEBUG"

and I got this error:

make: *** No rule to make target `-std=c++0x-o3', needed by `icpc'. Stop.

So, as you said, I need to specify it somewhat in the rules...

Your makefile sets the first task to be the building of icpc; as intermediate steps, you asked to build files named the same as your options. That can't be what you intended.
Please start with simple examples, e.g. from the manual

If you want to have all compilations of .cpp files which you don't take care of specifically use CXXFLAGS, you would have a rule at the bottom like

.cpp.o:
$(CXX) $(CXXFLAGS) -c $*.cpp

That rule should exist by default as an implicit rule.

If you're using netcdf, you must be able to get a working example to start from.

Thanks TimP, I tried to adapt what I found in other forums to my case, but it will definitely better to start from the beginning (I don't have so much time so I was trying to avoid that, as I'm not suposed to modify the makefile, but it's the only way I found to avoid the bug.

Cheers

You can over-ride makefile variables at invocation, e.g.
make CXX=icpc CXXFLAGS='-fp-model source -std=c++0x'
should you choose to do so, but perhaps you should use icpc.cfg

Unfortunately that didn't work, so I'll try with the icpc.cfg

Thank you!!

I finally could do it with the help of a friend.. It was quite silly, as the first thing I tried was to add the flag -std=c++0x to the CXXOPTIONS, but I had two (one general, and another for the options, I think)...and I just had tried the general. Adding the flag to the other CXXOPTIONS it worked perfectly... Newbie's stupid mistakes...

Thanks a lot!

We found this issue can reproduce with the latest version and gcc 4.5.1 on Fedora 14.

I found our new version fixed this issue now.
Could you double check it?

Thanks,
Wise

Wise, I think I can validate that the newest version is working. I was having this problem when compiling openmpi 1.4.3 on F14 (I think it was with 11.1, though), updated to 2011.4.191, and openmpi compiled fine.