__TBB_EXCEPTIONS status

__TBB_EXCEPTIONS status

I've got the 21.017 commercially-aligned open source release binaries and the reference manual revision1.13 PDF, working in Visual Studio 2008 SP1. There is a chapter on exceptions and there is a table of preprocessor symbols that enable optional features.The symbol __TBB_EXCEPTIONS is not mentioned in either place but the exception support seems to be off by default.

The latest blog traffic that I was able to find using "tbb exceptions" was from 2007, which is also the oldest date in the revisions table of the reference manual PDF. No major changes to the exception stuff are mentioned since then.

I'm coming to TBB cold and trying to use it in a massive legacy Windows application. Getting the "impedance match" right is pretty challenging. I'd appreciate a brief update on the status of the exception and cancellation stuff and some kind of authoritative information on whether I can enable it with the binaries I have and/or by recompiling from source.

Thanks,
-swn

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

__TBB_EXCEPTIONS is on by default for a while, including the latest 2.1 updates. To enable it, you should just ensure that you compile the code with exception support enabled (which I believe is "on"by default for popular C++ compilers).
You are right that the cancellation & exception propagation support in parallel algorithms was not documented; this will be fixed soon. Anyway, it is an official, supported feature. The __TBB_EXCEPTIONS macro however is internal, thus not documented.

Should you have any problems with using the feature in your apps, please let us know - either in the forum, or via Intel Premier Support.

Quoting - Alexey Kukanov (Intel)
You are right that the cancellation & exception propagation support in parallel algorithms was not documented; this will be fixed soon. Anyway, it is an official, supported feature. The __TBB_EXCEPTIONS macro however is internal, thus not documented.

Should you have any problems with using the feature in your apps, please let us know - either in the forum, or via Intel Premier Support.

You got ahead of me on the undocumented overloads on the parallel_foo stuff. The basic exception processing mechanism is documented in chapter 9 of revision 1.13 but in the 21.017 open source release the internal preprocessor symbol is off by default in Visual Studio, ia32 and em64t.

It's not immediately clear that turning it on in my code will help, since the DLL was compiled either with it or without it and I really don't know which.

Consider this letting you know, I guess. It looks like I'm going to need to build this puppy from source.

-swn

Quoting - Steve Nuchia
... in the 21.017 open source release the internal preprocessor symbol is off by default in Visual Studio, ia32 and em64t.

It switches on automatically in the header if compilation is being done with exception support enabled. Use /EH switch, or corresponding VS project setting.

The corresponding code in include/tbb/tbb_stddef.h should be as the following (check if it is the same in your installation):

#if defined(__EXCEPTIONS) || defined(_CPPUNWIND) || defined(__SUNPRO_CC)
#ifndef __TBB_EXCEPTIONS
#define __TBB_EXCEPTIONS 1
#endif /* __TBB_EXCEPTIONS */
#endif

_CPPUNWIND is defined by the Visual C++compiler in case the mentioned option is set.

Quoting - Alexey Kukanov (Intel)

_CPPUNWIND is defined by the Visual C++compiler in case the mentioned option is set.

That symbol is documented as being turned on by the /GX flag, which is deprecated as of VS2005. There's no mention of it in association with /EH. We're using /EHa in VS2008 SP1 for all build configurations.

I just bleeping love Microsoft compilers.

Any idea what compiler was used to produce the binaries on the open source site?

_CPPUNWIND is documented as being associated with some /EH forms in the /U (undefine predefined macros) flag page for the VS9SP1 compiler as well as other recent versions.

http://www.geoffchappell.com/viewer.htm?doc=studies/msvc/cl/cl/options/g...

Wow, there's an edifice of a website. It looks like /EHa does not define _CPPUNWIND. Sigh.

Quoting - Steve Nuchia
Any idea what compiler was used to produce the binaries on the open source site?

In case you still are interested in the answer, the binaries are produced by the Intel C++Compiler. You might see the exact version by setting TBB_VERSION environment variable, running a TBB example, and looking at stdout; BUILD_COMPILER line will contain the information of interest.See TBB_VERSION in the Reference to find what other info is printed out this way.

Best Reply

Quoting - Steve Nuchia
It looks like /EHa does not define _CPPUNWIND. Sigh.

It seems we missed this point. It's an interesting info; thanks for telling.

Anyway, the TBB binaries are built with /EHsc and contain the support for cancellation & exceptions, believe me. In the next version of TBB we will not check _CPPUNWIND anymore, just set the macro to 1 unless it is already specified. For now, I recommend you to specify it explicitly in your project file settings (or in command line).

Quoting - Steve Nuchia
It looks like /EHa does not define _CPPUNWIND. Sigh.

I did a quick check, and the above does not seem to be true. See the source file I used for this test:

// empty.cpp
int main() {
    return _CPPUNWIND;
}

I passed the following command to the compiler:
cl /EHa /EP empty.cpp
which should just parse the file with the preprocessor, and print the result out. With both VS2005 and VS2008, I got the following:

int main() {
    return 1;
}

And when Iremoved/EHa from the above command line, I got the source file unchanged in the output.
To me, this means /EHa does define _CPPUNWIND to 1.

Thanks for the citation and for recognising the scale of my work. However, I must protect what little reputation I have. Among those old pages about the Visual C++ compiler, I do note that /EHa _does_ imply /D_CPPUNWIND. See for instance, the page about /EHa itself and also about /u.

Geoff.

Quoting - geoffchappell

Thanks for the citation and for recognising the scale of my work. However, I must protect what little reputation I have. Among those old pages about the Visual C++ compiler, I do note that /EHa _does_ imply /D_CPPUNWIND. See for instance, the page about /EHa itself and also about /u.

Geoff.

No defamation intended, I assure you. Something in the combination of settings we arrived at to make our very large code base with 25+ years of history in it compile under VS2008 led to the symbol being undefined in our builds and I felt like your work provided much more in the way of a clue than anything on MSDN. Rather than chase the issue down to its fundamental elements I just posted the link and forced the symbol to 1 in my build settings.

Sloppy but effective. I've been on vacation and slept some since then but it's entirely possible I "misquoted myself" as to what flag I was thinking of.

Anyway, the precompiled DLL is forwarding exceptions exactly as expected now. Being in the bad old commercial programming world, that meansI don't get to spend anymore cycles on understanding this issue.

-steve

Leave a Comment

Please sign in to add a comment. Not a member? Join today