You are on page 1of 10

Developer Zone

intel c++ 11.1.072 and gcc 4.5.0

Alin M Sat, 05/29/2010 -


Ele na 10:56
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

Pleas e find the bug.cpp in theattachm ent.

Attachment Size

Download bug.cpp 1.61 KB

Without Questions there are no Answers!

Top RSS
39 posts / 0 new Last post

For more complete information about compiler optimizations, see our Optimization Notice.

Tim Prince Sat, 05/29/2010 - 12:58 to post

For what it's worth, the headers in the opens us e 11.1 iom anip are like
inline _Res etios flags
res etios flags (ios _bas e::fm tflags __m as k)
comments

{
_Res etios flags __x;
__x._M_m as k = __m as k;
return __x;
}
while the newer ones in m y ins tallation s till define _Res etios flags without us ing it:

inline _Res etios flags


res etios flags (ios _bas e::fm tflags __m as k)
{ return { __m as k }; }

s o I gues s the work-around for now would be to us e from an earlier opens us e.

Top

Alin M to post
Ele na Sat, 05/29/2010 - 15:03 comments
I am us ing 11.2 s o I am notexperiencingin real life this bug... It cam e out in real life tes ting of 11.3... Alin

Without Questions there are no Answers!

Top

Fe ilong H (Inte l) Tue, 06/01/2010 - 00:13 to post

Hi Alin,
comments

This is a known is s ue in our problem -tracking databas e. I'll let you know when I have an update regarding it.
Thank you.
--
Feilong H.
Intel Developer Support

Tools Knowledge Bas e: http://software.intel.com/en-us/articles/tools (http://software.intel.com/en-us/articles/tools)

Top

dacrim Thu, 07/01/2010 - 05:55 to post

Has there been a res olution to this is s ue yet? We are als o experiencing it and need to find a s olution.
comments

Regards ,

Dave

Top

Fe ilong H (Inte l) Thu, 07/01/2010 - 18:15 to post

Hi Dave,
comments

Our engineering team is s till working on a fix for this is s ue. I'll keep you guys updated when I have an update.
Thanks ,
Feilong

Top

Fe ilong H (Inte l) Mon, 07/26/2010 - 19:19 to post

comments
Engineering team has im plem ented a fix for this in the next m ajor vers ion of the com piler. I'll let you know when the com piler
that contains the fixis available for download.

Thanks ,
Feilong

Top

jim de m ps e yatthe cove Thu, 07/29/2010 - 06:02 to post


comments
There are two problem as I s ee it

1) return { __m as k }; as s um es a convers ion operator will take place


try return ( _Res etios flags ){ __m as k }; or reinterpret...
or us e the explicit convers ion operator=() as tim 18 illus trates
(note the optim izations will rem ove the __x and "fix" the bit field.

2) INTEL s upportread this "fixing" the code to im plicitly perform the convers ion weakens the s trong type checking of C++ and
m ay break code relying on tem plates to dis am biguate code expans ions . In particular tem plates that us e the hack of the
enableif... to enable expans ion as function.

By "fixing" this code exam ple, m ay require the program m ers to ins ert a plethora of "don't convert" functions /tem plates .

Jim Dem ps ey

www.quickthreadprogramming.com

Top

M ark us Hilt Thu, 08/19/2010 - 08:04 to post

Maybe I have found a workaround for this s pecial problem :


comments

I've jus t ins talled the package 'libs tdc++43-devel' which provides the include files of GCC 4.3 in the directory
'/us r/include/c++/4.3'. If the environm ent variable GXX_INCLUDE points to this direcory the ICC us es the include files in this
directory which s olves the problem on m y com puter.

So, jus t add the following line to you .bas hrc (or m aybe to the iccvars .s h) and the icc s hould work...

export GXX_INCLUDE=/us r/include/c++/4.3

Bes t regards
Markus Hilt

Top

Thom as Wed, 09/01/2010 - 14:33 to post

comments

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 s till pres ent in the lates t 11.1.073 com piler vers ion. When will a final bugfix, i.e. a new m ajor vers ion, be
available?

This is an annoying bug for all C++ developers us ing openSUSE s ys tem s . The Novell bugzilla entry
https://bugzilla.novell.com/show_bug.cgi?id=610073 has been clos ed as the problem can only be s olved by Intel.

Could the priority at Intel to finally fix this problem and get the fix out to all developers pleas e be rais ed. Thanks .
Top

Fe ilong H (Inte l) Wed, 09/01/2010 - 18:59 to post

Thom as ,
comments

You are right. This is s ue won't be fixed in 11.1 com piler. The fix will be in 12.0 com piler.

Thanks ,
Feilong

Top

Thom as Thu, 09/02/2010 - 15:12 to post

Quoting Feilong H. (Intel) Thomas,


You are right. This is s ue won't be fixed in 11.1 com piler. The fix will be in 12.0 com piler.
comments

Thanks ,
Feilong

Thanks for the confirm ation. Any rough idea when the 12.0 vers ion m ight be available? I m ean, are we talking about weeks ,
m onths , or even 2011... Any hints would be appreciated.

Top

Tim Prince Thu, 09/02/2010 - 17:39 to post

Intel 12.0 com piler releas e has been quoted on thes e forum s as planned before end of year.
Maybe there will be a new round of catch-up, as gcc 4.6.0 s hould be in general us e by then.
comments

Top

graziano.giulianigm ail.com Sun, 09/26/2010 - 06:39 to post


comments
My pers onal fix on Arch Linux (4.5.1 g++), obvious ly on s ys tem header, is attached.

Attachments:

Attachment Size

Download 4.5.1.patch 2.92 KB

Top

Tim Prince Sun, 09/26/2010 - 06:51 to post

comments

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 s im ply copied an earlier vers ion of the header which m ay have been tes ted with current icpc (the s am e
s ugges tion m ade early in this thread). I s uppos e this ris ks breaking the new g++.

Top

graziano.giulianigm ail.com Thu, 09/30/2010 - 00:40 to post


comments
No, it does not break g++, it does only us e "old" vers ion of header for icpc us ing the INTEL_COMPILER m acro defined by icpc
and not by g++ to decide which one to us e.

Top
M ark us Hilt Wed, 11/10/2010 - 02:22 to post

comments
Intel com piler s uite 12.0 is now available (now called the Intel Com pos er XE). However, as far I can s ee the problem has NOT
been fixed. When I us e Intel Com piler 12.0.0.084 (Intel C Intel 64 Com piler XE for applications running on Intel 64, Vers ion
12.0.0.084 Build 20101006) I s till get the following error m es s ages :

/us r/include/c++/4.5/iom anip(64): error: expected an expres s ion


{ return { __m as k }; }
^

/us r/include/c++/4.5/iom anip(94): error: expected an expres s ion


{ return { __m as k }; }
^

/us r/include/c++/4.5/iom anip(125): error: expected an expres s ion


{ return { __bas e }; }
^

/us r/include/c++/4.5/iom anip(193): error: expected an expres s ion


{ return { __n }; }
^

when I try to com pile this little piece of code

[cpp]#include
#include

using namespace std;

int main()
{
cout<<"hello icc"<
I am us ing OpenSUSE Linux 11.3 and gcc 4.5 (gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revis ion 160292]).

Bes t regards
Markus

Top

qtl Wed, 11/10/2010 - 03:30 to post

I am us ing g++ 4.5.1 and the new icpc 12,


/us r/include/c++/4.5.1/iom anip(64): error: expected an expres s ion
{ return { __m as k }; }
comments

/us r/include/c++/4.5.1/iom anip(94): error: expected an expres s ion


{ return { __m as k }; }
^

/us r/include/c++/4.5.1/iom anip(125): error: expected an expres s ion


{ return { __bas e }; }
^

/us r/include/c++/4.5.1/iom anip(193): error: expected an expres s ion


{ return { __n }; }
^

/us r/include/c++/4.5.1/iom anip(223): error: expected an expres s ion


{ return { __n }; }
^

com pilation aborted for ts t.cpp (code 2)

Top

Tim Prince Wed, 11/10/2010 - 09:08 to post


comments
Yes , I s ee the s am e, running on Red Hat 6. If I s et PATH tem porarily to the Red Hat g++ 4.4.4, no problem , but with the g++

4.5.1 downloaded from gfortran wiki, s am e errors as reported above.

Top

s te ve npclark Tue, 11/16/2010 - 20:25 to post

This problem is biting m e as well. I s ee it both in 11.1 and in 12.0.


comments

Really annoying!!!

Top

rda@rincon.com Wed, 11/17/2010 - 09:26 to post

Try adding this com piler flag to "fix" it: -s td=c++0x


comments

In 4.5, gcc is s tarting to us e s om e c++0x s yntax (s pecifically "initializer lis ts " - s ee


http://en.wikipedia.org/wiki/C%2B%2B0x#Initializer_lists (http://en.wikipedia.org/wiki/C%2B%2B0x#Initializer_lists) ). In
gcc, there's a m agic pragm a "#pragm a GCC s ys tem _header" that apparently perm its c++0x cons tructs in gcc header files
without explicitly enabling c++0x s upport. Try this in a .cc file, it fails without the extra -s td flag. Put it in an include file, it als o
fails . Add the m agic pragm a (to the include file) and it's accepted and s ucceeds .

Intel could try to m im ic the behavoir of "#pragm a GCC s ys tem _header", which would m ake this is s ue go away.

Top

s te ve npclark Wed, 11/17/2010 - 12:13 to post

RDA-
comments

Thanks for the s ugges tion. Unfortunately, (with 11.1 at leas t) adding that flag jus t res ults in a DIFFERENT com pilation error:

BEFORE:
/us r/include/c++/4.5.1/iom anip(64): error: expected an expres s ion
{ return { __m as k }; }
^

/us r/include/c++/4.5.1/iom anip(94): error: expected an expres s ion


{ return { __m as k }; }
^

/us r/include/c++/4.5.1/iom anip(125): error: expected an expres s ion


{ return { __bas e }; }
^

/us r/include/c++/4.5.1/iom anip(193): error: expected an expres s ion


{ return { __n }; }
^

/us r/include/c++/4.5.1/iom anip(223): error: expected an expres s ion


{ return { __n }; }

AFTER:
/us r/include/c++/4.5.1/bits /s tringfwd.h(74): error: identifier "char16_t" is undefined
tem plate<> s truct char_traits ;
^

/us r/include/c++/4.5.1/bits /s tringfwd.h(75): error: identifier "char32_t" is undefined


tem plate<> s truct char_traits ;
^
[....m any m ore s im ilar errors ....]

/us r/include/c++/4.5.1/type_traits (106): error: expected a ">"


s truct rem ove_reference<_Tp&&>
^

/us r/include/c++/4.5.1/type_traits (136): catas trophic error: rvalue references not yet im plem ented
{ typedef _Tp&& type; };
^

com pilation aborted for tes t.cc (code 4)

Do I need to bum p back up to 12.0 for that com piler flag to work?

Thanks
-Steven

Top

Tim Prince Wed, 11/17/2010 - 12:48 to post

I did check that the cas e is accepted by icpc 12.0 under -s td=c++0x
That option is better im plem ented in 12.0.
comments

Top

dacrim Tue, 01/04/2011 - 15:02 to post

comments
Will 12.0 be available anytim e s oon? The new nam ing on the web s ite does n't m ake it clear what vers ion is available now.
However, s ection 3.6.4 "TR1 Sys tem Headers " s eem s to im ply that the current releas e is s till an 11.X vers ion which does not
fix this is s ue.

Is it pos s ible to get a beta vers ion of 12.0?

Top

Tim Prince Tue, 01/04/2011 - 18:32 to post

comments
xe 2011 is the m arketing nam e for the 12.0 com pilers . The beta licens es have expired; if you are s till within the active term of
your licens e, you can download the new com piler.

Top

Johnny to post
Wille m s e n Mon, 02/07/2011 - 01:41 comments
With vers ion 12.0.2 20110112 com piling with -s td=c++0x s till gives the s am e problem , but the workaround to us e CPPFLAGS
+= -s td=c++0x s till works .

Top

M ichae l Fox Wed, 03/02/2011 - 11:25 to post

I am evaluating icc vers ion 12.0.2, and this problem pers is ts on openSUSE 11.3 (x86_64)
VERSION = 11.3.
comments

Is there a fix, or s ould one us e a old iom anip.h file localy?

us r/include/c++/4.5/iom anip(64): error: expected an expres s ion


{ return { __m as k }; }
^

/us r/include/c++/4.5/iom anip(94): error: expected an expres s ion


{ return { __m as k }; }
^

/us r/include/c++/4.5/iom anip(125): error: expected an expres s ion


{ return { __bas e }; }
^
/us r/include/c++/4.5/iom anip(193): error: expected an expres s ion
{ return { __n }; }
^

/us r/include/c++/4.5/iom anip(223): error: expected an expres s ion


{ return { __n }; }

Thanks !

Top

as cotilla Sun, 04/03/2011 - 15:41 to post

Thanks a lot, rda, That worked perfectly for m e!!


comments

Top

as cotilla Mon, 04/04/2011 - 10:38 to post

comments
By the way, do you know how can I include the -s td=c+0x flag in a m akefile? I've tried "CXXFLAGS = -s td=c++0x", but it does n't
work..

Thanks in advance

Top

Tim Prince Mon, 04/04/2011 - 10:51 to post

comments
That would be a norm al way, if $(CXXFLAGS) is included explicitly in the rules for m aking .o files from C++ s ources . If the
Makefile us es ($CXXFLAGS), you would be adding the option to thos e already s et. This s urely depends on how the Makefile is
s et up.
If you wis h the flag to be always s et for icpc, you can include it in icpc.cfg in your com piler ins tallation.

Top

as cotilla Tue, 04/05/2011 - 05:34 to post

comments
Thank you Tim P. I'm s orry becaus e I'm a newbie and s till don't know very well how to do it. I wrote this in the m akefile:

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

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

and I got this error:

m ake: *** No rule to m ake target `-s td=c++0x-o3', needed by `icpc'. Stop.

So, as you s aid, I need to s pecify it s om ewhat in the rules ...

Top

Tim Prince Tue, 04/05/2011 - 07:04 to post

comments

Quoting ascotilla 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 = -s td=c++0x
DEBUG =-g -D DEBUG

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

and I got this error:

m ake: *** No rule to m ake target `-s td=c++0x-o3', needed by `icpc'. Stop.

So, as you s aid, I need to s pecify it s om ewhat in the rules ...

Your m akefile s ets the firs t tas k to be the building of icpc; as interm ediate s teps , you as ked to build files nam ed the s am e as
your options . That can't be what you intended.
Pleas e s tart with s im ple exam ples , e.g. from the manua (http://www.gnu.org/software/make/manual/make.html) l

If you want to have all com pilations of .cpp files which you don't take care of s pecifically us e CXXFLAGS, you would have a
rule at the bottom like

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

That rule s hould exis t by default as an im plicit rule.

If you're us ing netcdf, you m us t be able to get a working exam ple to s tart from .

Top

as cotilla Tue, 04/05/2011 - 09:52 to post

comments
Thanks Tim P, I tried to adapt what I found in other forum s to m y cas e, but it will definitely better to s tart from the beginning (I
don't have s o m uch tim e s o I was trying to avoid that, as I'm not s upos ed to m odify the m akefile, but it's the only way I found
to avoid the bug.

Cheers

Top

Tim Prince Tue, 04/05/2011 - 11:43 to post

You can over-ride m akefile variables at invocation, e.g.


m ake CXX=icpc CXXFLAGS='-fp-m odel s ource -s td=c++0x'
s hould you choos e to do s o, but perhaps you s hould us e icpc.cfg
comments

Top

as cotilla Tue, 04/05/2011 - 12:48 to post

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


comments

Thank you!!

Top

as cotilla Mon, 04/11/2011 - 08:38 to post

comments
I finally could do it with the help of a friend.. It was quite s illy, as the firs t thing I tried was to add the flag -s td=c++0x to the
CXXOPTIONS, but I had two (one general, and another for the options , I think)...and I jus t had tried the general. Adding the flag
to the other CXXOPTIONS it worked perfectly... Newbie's s tupid m is takes ...

Thanks a lot!

Top

Wis e Che n to post


(Inte l) Tue, 04/19/2011 - 02:19 comments
We found this is s ue can reproduce with the lates t vers ion and gcc 4.5.1 on Fedora 14.

Top

Wis e Che n to post


(Inte l) Tue, 05/10/2011 - 02:09 comments
I found our new vers ion fixed this is s ue now.
Could you double check it?

Thanks ,
Wis e

Top

Jas on Patton Thu, 05/12/2011 - 21:43 to post

comments
Wis e, I think I can validate that the newes t vers ion is working. I was having this problem when com piling openm pi 1.4.3 on
F14 (I think it was with 11.1, though), updated to 2011.4.191, and openm pi com piled fine.

Top

Back to original post

Terms of Use (http://www.intel.com/content/www/us/en/legal/terms-of-use.html)

*Trademarks (http://www.intel.com/content/www/us/en/legal/trademarks.html)

Privacy (http://www.intel.com/content/www/us/en/privacy/intel-online-privacy-notice-summary.html)

Cookies (http://www.intel.com/content/www/us/en/privacy/intel-cookie-notice.html)
(http:
//fac (http:
//twit (http:
//ww
eboo ter.co
k.co m/int w.lin
kedi
Look for us on: m/int elsof m/gr
n.co
Intel-
rzon
e)
eldev tware
elope
Devel
oper-
) oups/ English
Zone
-
3078

You might also like