Boost C++ Libraries: Ticket #10924: conversion of float/double to cpp_dec_float_100 causes hang before main() on cygwin https://svn.boost.org/trac10/ticket/10924 <p> It looks like g++ generates bad code for: </p> <pre class="wiki">cpp_dec_float_100 x = 1.0; </pre><p> A program with this line hangs with full cpu usage, never entering main(). If 1.0 is replaced with an integer the problem disappears. </p> <p> I'm using x86_64-pc-cygwin-g++ version 4.8.3, compiling with: </p> <pre class="wiki">g++ -g -o gcc_bug_test1 gcc_bug_test1.cpp -I "$BOOST_PATH" </pre><p> on a fresh install using setup-x86_64.exe with mirror cs.vt.edu. </p> <p> gcc_bug_test1.cpp : </p> <pre class="wiki">#include &lt;iostream&gt; #include &lt;boost/multiprecision/cpp_dec_float.hpp&gt; using namespace std; namespace mp = boost::multiprecision; int main(int argc, char *argv[]) { mp::cpp_dec_float_100 x = 1.0; // -3; return 0; } </pre> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10924 Trac 1.4.3 John Maddock Sun, 18 Jan 2015 19:04:09 GMT cc set https://svn.boost.org/trac10/ticket/10924#comment:1 https://svn.boost.org/trac10/ticket/10924#comment:1 <ul> <li><strong>cc</strong> <span class="trac-author">e_float@…</span> added </li> </ul> <p> Works for me with Mingw64 and msvc. Can you debug? What happens in GDB - does it get stuck in an infinite loop somewhere? </p> Ticket anonymous Sun, 18 Jan 2015 19:59:50 GMT <link>https://svn.boost.org/trac10/ticket/10924#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10924#comment:2</guid> <description> <p> The most computationally intensive operation in cpp_dec_float before main() is the generation of a static constant table of p<sup>2 for -128 &lt; p &lt; +128. </sup></p> <p> It would help us if you could std::cout &lt;&lt; "something clever" before and after the table is generated ? </p> <p> If you look near line 2345 in boost/cpp_dec_float.hpp, you will find a potential location for this diagnostic. </p> <p> Thank you for your report. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>John Maddock</dc:creator> <pubDate>Fri, 06 Feb 2015 18:38:01 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/10924#comment:3 https://svn.boost.org/trac10/ticket/10924#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Turns out this is quite a pervasive issue - if there are no long double math functions (as on cygwin) then a call such as: </p> <p> stdlibfunc(BIG_VALUE) </p> <p> may simply return infinity as BIG_VALUE gets silently converted to double inside "stdlibfunc". In this particular case it's frexp/ldexp that are basically returning nonsense and breaking the program invariants. </p> <p> Simplistic fix in <a class="ext-link" href="https://github.com/boostorg/multiprecision/commit/4340817fd818b80df2295060eafdf79549d88683"><span class="icon">​</span>https://github.com/boostorg/multiprecision/commit/4340817fd818b80df2295060eafdf79549d88683</a> </p> Ticket John Maddock Fri, 06 Feb 2015 19:03:38 GMT <link>https://svn.boost.org/trac10/ticket/10924#comment:4 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10924#comment:4</guid> <description> <p> Also added some assertions for the preconditions which get broken on cygwin: <a class="ext-link" href="https://github.com/boostorg/multiprecision/commit/ca1f4697724fbb3dc3afed465e2e027ef4d4522d"><span class="icon">​</span>https://github.com/boostorg/multiprecision/commit/ca1f4697724fbb3dc3afed465e2e027ef4d4522d</a> </p> </description> <category>Ticket</category> </item> </channel> </rss>