Boost C++ Libraries: Ticket #9161: two definitions of future_object_base in v1.53 and 1.54

anonymous — Wed, 25 Sep 2013 22:17:57 GMT

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;

component changed; owner set

viboes — Thu, 26 Sep 2013 18:05:52 GMT

owner set to Anthony Williams
component None → thread

owner, status changed

viboes — Thu, 26 Sep 2013 18:06:01 GMT

owner changed from Anthony Williams to viboes
status new → assigned

status changed; resolution set

viboes — Thu, 26 Sep 2013 18:08:17 GMT

status assigned → closed
resolution → wontfix

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.

status changed; resolution deleted

John Maddock — Fri, 27 Sep 2013 08:43:14 GMT

status closed → reopened
resolution wontfix

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 — Fri, 27 Sep 2013 17:22:40 GMT

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

            typedef shared_ptr<shared_state_base> continuation_ptr_type;

to see if just this fix the issue?

viboes — Fri, 04 Oct 2013 20:08:13 GMT

Committed revision [86162].

Jennifer.L.Jiang@… — Mon, 07 Oct 2013 04:14:24 GMT

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

Jennifer

viboes — Mon, 07 Oct 2013 05:17:11 GMT

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

status, milestone changed; resolution set

viboes — Tue, 08 Oct 2013 17:10:26 GMT

status reopened → closed
resolution → fixed
milestone To Be Determined → Boost 1.55.0

Committed revision [86202].