two definitions of future_object_base in v1.53 and 1.54

[jennifer.l.jiang@…]

Our testing with icpc on Linux found one strange issue related to “BOOST_THREAD_VERSION”.

When building the boost thread library (libboost_thread.a), we found that “BOOST_THREAD_VERSION” is defined as “2”, but when the test case (i.e set_exception_at_thread_exit_pass.cpp) is built, the “BOOST_THREAD_VERSION” is “4”. So when “-ipo” Is used, icpc gives link errors because two definitions of the same class “struct future_object_base : enable_shared_from_this<future_object_base>” is used.

But Gcc seems working fine with its whole program optimization.

[anonymous]

Adding more detail:

when “-ipo” Is used, icpc generates incorrect code because two definitions of the same class “struct future_object_base : enable_shared_from_this<future_object_base>” is used. At "-ipo", icpc treats those classes as two different classes. case1: =====

struct future_object_base : enable_shared_from_this<future_object_base> {

… shared_ptr<future_continuation_base> continuation_ptr;

case 2:

struct future_object_base : enable_shared_from_this<future_object_base>

{

…

shared_ptr<void> continuation_ptr;

[viboes]

I have no way to solve this issue.

If you want to use BOOST_THREAD_VERSION 4 I suspect that you will need to build Boost with this define.

[John Maddock]

As the person who suggested Jennifer file a bug report here I feel I should try and clarify the issue (Jennifer works for Intel: her interest is in testing their compiler against Boost, but of course this uncovers bugs in Boost as well as their compiler).

1) In the headers I see things like:

#if defined BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION
            typedef shared_ptr<shared_state_base> continuation_ptr_type;
#else
            // This type shouldn't be included, but is included to maintain the same layout.
            typedef shared_ptr<void> continuation_ptr_type;
#endif

So it appears that the intention is that the library should be binary compatible regards of the setting of BOOST_THREAD_VERSION? And yet that's clearly not the case - at least in the presence of IPO. At the very least this needs clearly documenting.

2) There are many tests which explicitly test version 3 or 4 features, but which still try and link against a library built with version 2. Again this won't work in the presence of IPO, and prevents the running of tests with IPO enabled (which is a good thing to test BTW). So IMO the Jamfile is broken - you should really build 3 versions of libboost_thread (for versions 2, 3 and 4) and link against the right one in each test. Clearly that's going to be tedious to fix, but I don't see how the current situation can be correct either (So it might actually be better to fix 1).

Let me know if you need someone to run the tests with Intel C++.

[viboes]

Replying to johnmaddock:

As the person who suggested Jennifer file a bug report here I feel I should try and clarify the issue (Jennifer works for Intel: her interest is in testing their compiler against Boost, but of course this uncovers bugs in Boost as well as their compiler).

1) In the headers I see things like:

#if defined BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION
            typedef shared_ptr<shared_state_base> continuation_ptr_type;
#else
            // This type shouldn't be included, but is included to maintain the same layout.
            typedef shared_ptr<void> continuation_ptr_type;
#endif

So it appears that the intention is that the library should be binary compatible regards of the setting of BOOST_THREAD_VERSION? And yet that's clearly not the case - at least in the presence of IPO. At the very least this needs clearly documenting.

I don't know what IPO is, but yes the intention was to have the same layout.

2) There are many tests which explicitly test version 3 or 4 features, but which still try and link against a library built with version 2. Again this won't work in the presence of IPO, and prevents the running of tests with IPO enabled (which is a good thing to test BTW). So IMO the Jamfile is broken - you should really build 3 versions of libboost_thread (for versions 2, 3 and 4) and link against the right one in each test. Clearly that's going to be tedious to fix, but I don't see how the current situation can be correct either (So it might actually be better to fix 1).

Let me know if you need someone to run the tests with Intel C++.

Could you replace

#if defined BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION
            typedef shared_ptr<shared_state_base> continuation_ptr_type;
#else
            // This type shouldn't be included, but is included to maintain the same layout.
            typedef shared_ptr<void> continuation_ptr_type;
#endif

by

            typedef shared_ptr<shared_state_base> continuation_ptr_type;

to see if just this fix the issue?

[viboes]

Committed revision [86162].

[Jennifer.L.Jiang@…]

the above suggested work-around in John's 2) worked for us.

Jennifer

[viboes]

Do you need this in release 1.55 or it is enough on trunk?

[viboes]

Committed revision [86202].