Re: [Boost-Users] Intel 7.0 Compiler problems

From: Miko (miko_at_[hidden])
Date: 2003-02-06 01:17:27

>From: <klapshin_at_[hidden]>

> Tired of MSVC deficiencies, and hoping to get certain performance
> increase I got evaluation version of Intel C++ compiler.

Sounds familiar. I did the same. :)

A nice thing about it, besides the conformance and optimisation, is that it
works as a drop-in replacement for MSVC, as you said, so you can use the
same IDE.

> I've heard
> lots of good things about this compiler, and was under impression
> that
> transition from MSVC to ICL should be very smooth. Huh, I had all
> kinds of troubles.

If you run it in "Microsoft mode" (the default), then the transition should
be smooth, as you say. However, that also means it emulates MSVC's bugs, so
that doesn't buy you that much. Only when setting the options to turn this
emulation off, does it show its true EDG nature, but then, as you say, the
transition may not be very smooth, as some things, such as the MSVC standard
library, are made for MSVC with its bugs, so using it with Intel C++ running
in strict mode gives a lot of errors for the library.

I also switched to STLPort, which I'm using for both MSVC and Intel C++.

> First of all boost 1.29 gave up saying that it is an unknown
> compiler.
> Looking into config I figured that last known ICL was 6.0, so I just
> hacked it badly by redefining ICL as 600 prior to including any boost
> headers.

This is fixed in the CVS, so it will be fixed in the next release, at least.

> I understand that it is not a good way, but hey, I am just
> evaluating it.
>
> Ok now everything compiled, but code using regex failed to link. No
> wonder, I have not build regex library with new compiler. It turns
> out
> that there is no makefile for any intel compiler, so I tried to do it
> with bjam, but seems that bjam did not set CC variable; it invoked
> compilation with just line of flags. At this point I gave up and
> decided to focus on parts of my project which do not depend on regex.

It should be possible to build it using the MSVC makefile, since it's
command-line compatible with it.

> Next surprise was when I tried to run tests, in debug mode everything
> was fine, but release mode failed miserably. It appears that
> date_time
> library does not work at all with optimization. Even setting /O1 did
> not help, only /Od worked.

Strange. If you manage to distil it down to a relatively simple test case,
you might submit it as a problem report to Intel. They have excellent
customer support.

> I searched through Boost Users and Dev mailing lists, found few posts
> discussing turning on strict ansi checks on intel, and also that in
> this case it is better to use STLport, since STL coming with MSVC
> could not be compiled in ansi mode.

Yes.

> I tried to do that but can't
> compile STLport in strict mode either. Using STLport in regular mode
> did not have any effect on problems I am having.

I think I had to make some changes to STLPort to make it work, as well, but
it works now, running in strict mode. Feel free to mail me off-list (as it's
not Boost specific) about the problems and errors you get, and I may be able
to help.

> Now, my question is: are these problems well known? If they are, is
> there any plans to fix them in next release?

It seems some of this is not related to Boost. Since the Date/Time library
works in debug mode, but fails in release mode, it appears to be
compiler-related, instead. Unless there are some bugs in the library. You
may want to check the same code on another compiler, for example MSVC, or
g++. That should show if it's the compiler or library.

> And while we at it, when should we expect new release? I know there
> were some discussions about mid-February, is there any update?

The schedule that has been posted, and recently confirmed, is:

 >The tentative release schedule for 1.30.0 looks like:
 >
 >   January 31 - Finish commits of major new components.
 >   February 14 - Branch for release.
 >   By end of February - Final release.

By the way, the options I use for Intel C++ is:

-Qoption,cpp,--strict,--arg_dep_lookup,--no_microsoft_bugs,--no_guiding_decl
s,--dep_name

You'll find a description of these in the EDG manual at the EDG site. The
first three should be obvious. no_guiding_decls is a pre-standard thing, and
"guiding declarations" is on by default, for MSVC emulation, but it breaks
code with overloaded function templates. dep_name turns on two-phase lookup,
which is also off by default, for the same reason.

There's also the option: /Zc:wchar_t which makes wchar_t an intrinsic
character, rather than an alias for unsigned short, as in MSVC 6.

Regards,

Terje