Fixing problems with the Intel compiler using a GCC 4.4 std library

[sithhell]

This PR solves a problem with using the intel compiler series with a standard library provided by gcc 4.4.x standard libraries.

[K-ballo]

This is surprising, the problems fixed here happen when using GCC4.6 as a standard library, at least according my reading of the logs here. Either this change doesn't do anything, or somehow Intel ends up using 4.6 standard library sources while pretending to be 4.4 compiler. That's a huge gap, for instance it means "0.9 rvalue references" (with different implicit special member rules for instance) instead of the real thing, it could easily explain the problems we are seeing. Basically what it means is that we are still supporting GCC4.4, the question is how has this worked so far?

[sithhell]

@K-ballo: I think the problem at hand is slightly more complicated. Our intel 13 builder indeed uses the stdlib from 4.6. The PR description is wrong then. We see two failures:

1. Intel 13 + gcc 4.6 stdlib isn't able to properly generate the code needed for moving the std::pair (for whatever reason)
2. Intel 14 + gcc 4.4. stdlib experiences the same problem.

I am not entirely sure why this is happening. That doesn't mean we still support gcc 4.4, we don't support the compiler frontend. We merely have to support its stdlib. Unfortunately most systems only come equipped with gcc 4.4 plus some version of the intel compiler. The intel compiler itself supports all the necessary C++11 features we need though.

[sithhell]

It has worked so far because we already implemented a few workaround in similar situations. The use of std::unique_ptr in the core library was only introduced with our new serialization layer. As such we never noticed those problems before (except with hpx::util::serialization_buffer<T> where we applied a different workaround).

[hkaiser]

LGTM

[K-ballo]

We should figure out what this means for us, other than no movable-only types on maps.

[hkaiser]

@Finomnis: could you please add/change an Intel V13 builder on buildbot to use stdlibc++ 4.4? This would reproduce the issue and would avoid running into similar issues in the future.

[K-ballo]

@Finomnis: could you please add/change an Intel V13 builder on buildbot to use stdlibc++ 4.4? This would reproduce the issue and would avoid running into similar issues in the future.

It does not look like that would reproduce the issue. See 4.4 vs 4.6, they operate under different language rules and each one is correct for the compiler that they target. What we would need is the cross product of all Intel versions we are willing to support with all the "compatibility gcc modes" we are willing to support.

[hkaiser]

What we would need is the cross product of all Intel versions we are willing to support with all the "compatibility gcc modes" we are willing to support.

I'd suggest to support the most commonly used combinations, one for each compiler version. That also implies that we should add build system support to detect those combinations while rejecting all others (at least issuing a warning).

[sithhell]

This PR is removing a compilation error for a particular set of compiler +
stdlib combination. Nothing more. All the other things discussed here are
quite orthogonal.

[K-ballo]

Missing include for boost::shared_ptr usage here

[sithhell]

Thanks, fixed.

[sithhell]

On Saturday, April 25, 2015 08:38:12 Agustín Bergé wrote:

@Finomnis: could you please add/change an Intel V13 builder on buildbot to
use stdlibc++ 4.4? This would reproduce the issue and would avoid running
into similar issues in the future.
It does not look like that would reproduce the issue. See
[4.4](https://github.com/gcc-mirror/gcc/blob/gcc-4_4_0-release/libstdc%2B%2
B-v3/include/bits/stl_pair.h#L92) vs
[4.6](https://github.com/gcc-mirror/gcc/blob/gcc-4_6_0-release/libstdc%2B%2
B-v3/include/bits/stl_pair.h#L115), they operate under different language
rules and each one is correct for the compiler that they target. What we
would need is the cross product of all Intel versions we are willing to
support with all the "compatibility gcc modes" we are willing to support.

Yes, that would be the best thing to do. I think we can phase out intel13
compiler support soon. AFAICT, most clusters have at least intel14 available
and are switching to default to intel V15.