Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2

Subject: Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-27 23:29:12

On 27/01/2018 22:06, Glen Fernandes wrote:
> On Sat, Jan 27, 2018 at 4:55 PM, Glen Fernandes  wrote:
>> I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux
>> with libstdc++ with -std=c++14 and -std=c++1z which fails with many
>> errors:
>>
>> e.g.
> [snip]
>> In file included from
>> libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34:
>> libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42:
>> error: no template named 'conditional_t' in namespace 'std'; did you
>> mean 'conditional'?
>> template <class T> using devoid =
>> std::conditional_t<std::is_void<T>::value, void_type, T>;
>> ~~~~~^~~~~~~~~~~~~
>> conditional
>> /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12:
>> note: 'conditional' declared here
>> struct conditional

That's an ancient version of libstdc++ 4.8 which does not provide
sufficient C++ 14 support.

As the documentation says at
https://ned14.github.io/outcome/requirements/, you need GCC 6.3 or later.

Thus libstdc++ would also need to be 6.3 or newer.

>> Then I also tried the boost-outcome unit tests with Apple clang 8.1.0
>> with libc++ with -std=c++14 and -std=c++1z which fails with errors
>> like:

Again, as https://ned14.github.io/outcome/requirements/ says, XCode 9 or
newer is required. The implementation of C++ 14 in XCode 8 is insufficient.

>> Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on
>> Linux seem to pass. The other combinations I tried (clang + lisbtdc++
>> on Linux,   Apple clang + libc++) do not.
>>
> 
> I spoke too soon, here gcc 7 does not pass. It ICEs:
> [snip]
> Let me know if you need more context, but it appears boost-outcome is
> also broken on gcc 7.2.

There's a long standing memory corruption bug in GCC's constexpr
implementation which Outcome's unit tests may trigger sometimes.

The GCC maintainers know well of this bug, and efforts continue to track
it down and fix it. The problem is that it is not repeatable across
machines. I may get consistently an ICE here on my machine (I do!), but
Travis running the exact same compiler and test suite does not (also
true!). Same problem when say Jason Merrill runs a repro I send him, and
it works perfectly on his machine, yet ICEs on mine.

If you're using Outcome heavily in 100% constexpr programming, then you
are advised to use clang or - and I kid you not here - MSVC until GCC
gets its constexpr implementation fixed.

Again, none of this is Outcome's fault. These are bugs in compilers. I
would also add that in day to day programming, GCC's constexpr problems
don't really manifest. They appear only when heavily stressed in say a
test suite which runs lots of corner case scenarios that would never
happen in real life.

Equally, if when programming with Outcome and you see GCC ICEing in
constexpr, either remove the constexpr or use a different compiler.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/