boost 1.78.0 (and many previous versions?) do not support the documented GCC versions.. "This library now requires a C++11 or later compiler" should minimal requirements be updated?

[gcflymoto]

Cross-filed with boostorg/multiprecision#420

As documented on the release notes

"""
Boost's primary test compilers are:

Linux:
...
GCC, C++11: 4.7.3, 4.8.5, 11
"""

But this does play out in practice.. compiling with GCC4.7.3, GCC4.8.5 with -std=c++ fails. Should the release notes change?

boost/1.78.0/boost/multiprecision/detail/number_base.hpp:36:2: error: #error "This library now requires a C++11 or later compiler - this message was generated as a result of BOOST_NO_CXX11_HDR_TYPE_TRAITS being set"

/usr/bin/gcc/4.7.3/bin/g++ -c -std=c++11 -fPIC -DBOOST_PP_VARIADICS test.cpp

from test.cpp:13:
/usr/boost/1.78.0/boost/multiprecision/detail/number_base.hpp:36:2: error: #error "This library now requires a C++11 or later compiler - this message was generated as a result of BOOST_NO_CXX11_HDR_TYPE_TRAITS being set"
/usr/boost/1.78.0/boost/multiprecision/detail/number_base.hpp:48:2: error: #error "This library now requires a C++11 or later compiler - this message was generated as a result of BOOST_NO_CXX11_REF_QUALIFIERS being set"
/usr/boost/1.78.0/boost/multiprecision/detail/number_base.hpp:72:2: error: #error "This library now requires a C++11 or later compiler - this message was generated as a result of BOOST_NO_CXX11_REF_QUALIFIERS being set"
/usr/boost/1.78.0/boost/multiprecision/detail/number_base.hpp:92:0: warning: ignoring #pragma GCC warning [-Wunknown-pragmas]
In file included from /usr/boost/1.78.0/boost/multiprecision/cpp_int.hpp:14:0,
from /usr/boost/1.78.0/boost/multiprecision/integer.hpp:10,
from test.cpp:13:

The same happens with GCC 4.8.5 ... the lowest GCC that works for me is 5.3.0

[ckormanyos]

a non C++11 conforming compiler

There is some discussion here. What are considered interpretatins of a C++11 compiler? Which compilers CI?

I/we could take a try at more details in the docs. In the GCC world, I feel that C++11 is 5.2, 5.3, 5.4 or higher.
I believe we only test these days in CI at GCC6 and higher.

I don't knoe when an MSVC might be considered C++11 ( I think all the way up to MSVC 2017). And the clang story i also do not know.

What happens if somewone goes for GCC 5.2, which may very wel compile Math/Multiprecision, but might not be in CI.

We should describe, elucidate and narrow these fields in docs in my opinion...

See also related issue

Cc: @mborland and @jzmaddock

[gcflymoto]

Yes, it looks like the minimum is 5.2 from my testing to compile boost MP.

[jzmaddock]

I agree the top level release notes are incorrect here - we decided some time ago on the ML that libraries could drop C++03 support, and that means dropping compilers with only pre-C++03 support from the "primary" list in the release notes IMO. @pdimov, @mclow does anything need to change other than the docs? How do the release managers feel about this?

[mclow]

I'll just point out here that Tom Kent runs test bots that test gcc 4.6, 4.7, 4.8, and 4.9 (and others)
See https://www.boost.org/development/tests/master/developer/summary.html

[gcflymoto]

@mclow and multi-precision fails on all of those:

https://www.boost.org/development/tests/master/developer/multiprecision.html

[pdimov]

I don't knoe when an MSVC might be considered C++11 ( I think all the way up to MSVC 2017).

The earliest MSVC version that can be considered reasonably C++11 is MSVC 2013 (it doesn't support constexpr and noexcept). The earliest kind of "fully conforming" C++11 is 2015.

And the clang story i also do not know.

All versions of Clang we have on CI are C++11, but on Linux it can use the underlying GCC stdlib, and that's only reasonably C++11 starting from 4.8, and "fully conforming" from 4.9 or 5.

[pdimov]

More generally, this is exactly why I argued (at length) that the decision to move to C++11 as minimum needs to be done on the Boost project level, rather than at the individual library level, but, here we are.

[jzmaddock]

and multi-precision fails on all of those:

As expected, we no longer support pre-c++11 compilers.

More generally, this is exactly why I argued (at length) that the decision to move to C++11 as minimum needs to be done on the Boost project level, rather than at the individual library level, but, here we are.

I thought the consensus was that libraries could if they wished (provided suitable notice was given) drop support for pre-C++11 compilers? If that's the case then anything prior to gcc-5 should be considered "optionally" supported?

[ckormanyos]

But this does play out in practice.. compiling with GCC4.7.3, GCC4.8.5 with -std=c++ fails. Should the release notes change?

boost/1.78.0/boost/multiprecision/detail/number_base.hpp:36:2: error: #error "This library now requires a C++11 or later compiler - this message was generated as a result of BOOST_NO_CXX11_HDR_TYPE_TRAITS being set"

I was going over this thread again. There are quite a few ins-and-outs here.

Then I got a bit sad.

The original quote above caught my attention. When we went C++11 in Multiprecision, we decided to drop support (purposely) for non-C++11 compilers. But we did not exactly specify which compilers retain support. The exact compilers mentioned above actually do have some preliminary version(s) of <type_traits>. But these are only activated when -std=c++11 is specified on the command line.

Then I was wondering about the scope and determination of this post. I think getting us to roll back on C++11 in either Math or Multiprecision would be something we authors of those packages would resist to some extent.

In summary, I hope we did not overlook anything too big. I had thought we were well within the spirit of Boost when going with C++11. In fact, I had believed it was a completely optional on a library-to-library basis to make the choice to require C++11. John has mentioned this above.

As a final technical remark, I think we could more clearly state which compilers do/do-not work with Math/Multiprecision. Going back to 5.2 might be within reach. But I think dropping the C++11 requirments would require some negotiation and might not be well received by all library authors in Math/Multiprecision.

[pdimov]

I think that we should probably take GCC 4.6 and 4.7 out of our primary test compilers, because most of our primary testing is now done with Github Actions and 4.8 is the minimum there (if one doesn't want to bother with docker images of 16.04.)

I'm not sure that the early Clangs can also reasonably be called primary, because the earliest on GHA is 3.9 now.

Also, our primary compiler list doesn't reflect the relative importance of the targets, because the default -std level for GCC until 6.0 is -std=c++98, and -std=c++14 onwards (until 11, when it changes to c++17). And the default is important because that's how the distros build Boost.

As for Multiprecision itself, it's your choice whether to support GCC 4.8 or not. It's almost C++11, but not entirely. I wouldn't be opposed to declaring GCC 5 the earliest usable C++11 compiler, and updating the primary compiler list to reflect that.

I thought the consensus was that libraries could if they wished (provided suitable notice was given) drop support for pre-C++11 compilers?

A significant fraction of Boost users view Boost as a single thing and don't really care for our internal consensus (to the extent that it exists.) If Boost effectively requires GCC 5 and C++11 now to be usable, or if it effectively requires GCC 5 in order for its C++11 portions to be usable, this should be reflected in the Boost release notes.

[ckormanyos]

It is good to read the advice above.

As for Multiprecision itself, it's your choice whether to support GCC 4.8 or not. It's almost C++11, but not entirely. I wouldn't be opposed to declaring GCC 5 the earliest usable C++11 compiler, and updating the primary compiler list to reflect that.

From the operational perspective, does it help anything to strive to get Math/Multiprecision back tested and released for GCC 5.2? Or has that already sailed?

We would need to guage the feasibility of this in the library team. Subjectively, I think 5.2 should/could be do-able, as it's a pretty good C++11 compiler. But along those lines, we would need the flag -std=c++11.

If it helps and if there is added value, I could look into CI for GCC 5.2 on these two LIBs --- but definitely post-1.79 in spring/summer. I might not get too far, but I could look.

Cc: @jzmaddock your thoughts on recovering GCC 5.2?

[pdimov]

I'm not sure what's the relevance of GCC 5.2? It's a minor version (a patch release), and GCC 5 is up to 5.5 now I think?

Note that the version scheme of GCC changed with 5 and above; the 2 in 5.2 is the equivalent of 5 in 4.8.5.

E.g. the base (as shipped) version of GCC on Xenial (Ubuntu 16.04 LTS), where it's the system compiler, is 5.3, and the updated version is 5.4, according to https://www.ubuntuupdates.org/package/core/xenial/universe/updates/gcc-5. I don't think there's any point of trying to support 5.2.

[ckormanyos]

I'm not sure what's the relevance of GCC 5.2?

I would like to know:

• Does supporting GCC 5.any help for the purposes of this thread or not?

I was, however, unaware (or forgot) the major/minor/patch philosophy change. Thx very much for reminding of that Peter (@pdimov).

[pdimov]

Since the default for GCC 6 is C++14, there's not much point in keeping the library C++11 if you don't support GCC 5.