Boost C++ Libraries: Ticket #13360: std::numeric_limits<multiprecision::float128> methods fail to compile in C++11 mode https://svn.boost.org/trac10/ticket/13360 <p> The following code compiles fine in C++03 mode, but fails in C++11 mode. This happens in boost 1.66.0, but didn't happen in 1.63.0. </p> <pre class="wiki">#include &lt;boost/multiprecision/float128.hpp&gt; int main() { std::numeric_limits&lt;boost::multiprecision::float128&gt;::min(); } </pre><p> Similar problem with some other methods — those which return without explicit construction of <code>number_type</code>. </p> <p> I'm compiling with g++ using the following command line: </p> <pre class="wiki">g++ -std=c++11 boost-test.cpp -o boost-test -fext-numeric-literals -lquadmath </pre><p> The compiler prints the following error: </p> <pre class="wiki">In file included from boost-test.cpp:1:0: /usr/include/boost/multiprecision/float128.hpp: In instantiation of ‘static std::numeric_limits&lt;boost::multiprecision::number&lt;boost::multiprecision::backends::float128_backend, ExpressionTemplates&gt; &gt;::number_type std::numeric_limits&lt;boost::multiprecision::number&lt;boost::multiprecision::backends::float128_backend, ExpressionTemplates&gt; &gt;::min() [with boost::multiprecision::expression_template_option ExpressionTemplates = (boost::multiprecision::expression_template_option)0u; std::numeric_limits&lt;boost::multiprecision::number&lt;boost::multiprecision::backends::float128_backend, ExpressionTemplates&gt; &gt;::number_type = boost::multiprecision::number&lt;boost::multiprecision::backends::float128_backend, (boost::multiprecision::expression_template_option)0u&gt;]’: boost-test.cpp:4:59: required from here /usr/include/boost/multiprecision/float128.hpp:645:55: error: could not convert ‘3.3621031431120935062626778173217526e-4932’ from ‘__float128’ to ‘std::numeric_limits&lt;boost::multiprecision::number&lt;boost::multiprecision::backends::float128_backend, (boost::multiprecision::expression_template_option)0u&gt; &gt;::number_type {aka boost::multiprecision::number&lt;boost::multiprecision::backends::float128_backend, (boost::multiprecision::expression_template_option)0u&gt;}’ static number_type (min)() BOOST_NOEXCEPT { return 3.36210314311209350626267781732175260e-4932Q; } ^ </pre> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13360 Trac 1.4.3 John Maddock Mon, 25 Dec 2017 19:25:35 GMT <link>https://svn.boost.org/trac10/ticket/13360#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/13360#comment:1</guid> <description> <p> This is the by-product of fixing other issues, and I don't think we can fix it, except to say that using -std=gnu++11 works just fine. </p> <p> The issue is that <span class="underline">float128 literals are disabled with -std=c++11 but not -std=c++03 or -std=gnu++11. We can detect the -std=gnu++11 case and enable </span>float128 support in that situation, but we can't detect that -fext-numeric-literals has been used with std=c++11 so <span class="underline">float128 support is disabled in the library. </span></p> <p> I'll look into trying to support this case with more config macros, but it might be easier to just issue better error messages when including the header in this situation. </p> <p> Merry Christmas! </p> </description> <category>Ticket</category> </item> <item> <author>b7.10110111@…</author> <pubDate>Wed, 27 Dec 2017 10:45:48 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/13360#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/13360#comment:2</guid> <description> <p> Not sure if this is the core problem, but what if we use the following constructs instead of quad literals? </p> <pre class="wiki">using ldlims=std::numeric_limits&lt;long double&gt;; constexpr auto max=__float128(ldlims::max())+ __float128(0x1.ffffffffffffp+16383L)*0x1.p-64; constexpr auto min=__float128(ldlims::min()); constexpr auto denorm_min=__float128(ldlims::denorm_min())*0x1.p-49; constexpr auto epsilon=__float128(ldlims::epsilon())*0x1.p-49; </pre><p> These compile and work perfectly well with GCC (one of them, <code>denorm_min</code>, wasn't even implemented in boost, but is also doable, as shown above). </p> </description> <category>Ticket</category> </item> <item> <author>Ruslan Kabatsayev <b7.10110111@…></author> <pubDate>Wed, 27 Dec 2017 10:51:07 GMT</pubDate> <title>cc set https://svn.boost.org/trac10/ticket/13360#comment:3 https://svn.boost.org/trac10/ticket/13360#comment:3 <ul> <li><strong>cc</strong> <span class="trac-author">b7.10110111@…</span> added </li> </ul> Ticket b7.10110111@… Thu, 28 Dec 2017 21:16:49 GMT <link>https://svn.boost.org/trac10/ticket/13360#comment:4 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/13360#comment:4</guid> <description> <p> Actually, if we want to remain compatible to non-x87 FPUs, supporting IEEE754 binary64 as <code>double</code>, then we can do it this way: </p> <pre class="wiki"> constexpr auto max=(__float128(0x1.fffffffffffffp+1023) + 0x1.ffffffffffffp+970 + 0x1.ffcp+921) * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+1023 * 0x1p+15; constexpr auto min=__float128(0x1p-1022) * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-30; constexpr auto denorm_min=__float128(0x1p-1022) * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-1022 * 0x1p-142; constexpr auto epsilon=__float128(0x1p-112); assert(max==std::numeric_limits&lt;boost::multiprecision::float128&gt;::max()); assert(min==std::numeric_limits&lt;boost::multiprecision::float128&gt;::min()); assert(epsilon==std::numeric_limits&lt;boost::multiprecision::float128&gt;::epsilon()); </pre> </description> <category>Ticket</category> </item> </channel> </rss>