From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3244 invoked by alias); 15 Dec 2014 18:32:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 3173 invoked by uid 48); 15 Dec 2014 18:32:21 -0000 From: "zhouyan at me dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/64318] New: Using _Cilk_for with cause strange floating point exception Date: Mon, 15 Dec 2014 18:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: zhouyan at me dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-12/txt/msg01782.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64318 Bug ID: 64318 Summary: Using _Cilk_for with cause strange floating point exception Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhouyan at me dot com Below is a minimum example, #include int main () { std::mt19937 eng; std::normal_distribution<> rnorm; _Cilk_for (int i = 0; i != 10000; ++ i) rnorm(eng); } It is compiled with the following, $GCC_PATH/g++ -std=c++11 -fcilkplus -g -o test test.cpp $GCC_LDFLAGS where $GCC_PATH expands to where I installed the trunk version of GCC and $GCC_LDFLAGS is -L /opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/lib64 -L /opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/5.0.0 -Wl,-rpath -Wl,/opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/lib64 -Wl,-rpath -Wl,/opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/5.0.0 (Basically it avoids the program to find the system libstdc++ etc., at runtime) The GCC version is trunk, output of $GCC_PATH/g++ -v is Using built-in specs. COLLECT_GCC=/opt/GCC/devel/bin/g++ COLLECT_LTO_WRAPPER=/opt/GCC/devel/libexec/gcc/x86_64-redhat-linux-gnu/5.0.0/lto-wrapper Target: x86_64-redhat-linux-gnu Configured with: ../GCC-src/configure --build=x86_64-redhat-linux-gnu --prefix=/opt/GCC/devel --disable-multilib --disable-nls --disable-werror --enable-checking=release --enable-languages=c,c++,fortran --enable-libstdcxx-time=yes --enable-lto --enable-stage1-checking --enable-version-specific-runtime-libs --with-system-zlib Thread model: posix gcc version 5.0.0 20141215 (experimental) (GCC) The problem does not always shows up, but run the program enough times (or increase the loop count), sooner or later I encounter a floating point exception. Run the program through a debug, whenever the crash happens, it always happen in the following frame, thread #2: (some verbose output omitted) at random.tcc:3473 3470 = std::min(static_cast(std::numeric_limits<_RealType>::digits), 3471 __bits); 3472 const long double __r = static_cast(__urng.max()) -> 3473 - static_cast(__urng.min()) + 1.0L; 3474 const size_t __log2r = std::log(__r) / std::log(2.0L); 3475 size_t __k = std::max(1UL, (__b + __log2r - 1UL) / __log2r); 3476 _RealType __sum = _RealType(0); It since the cast from integer to long double cause the exception, which makes no sense. (And replace the random number generating to doing just this cast, the problem disappears) The problem does not occur with optimized code, and it seems that it does not occur with other distributions. For example, the frame at issue suggest it might be a problem in std::uniform_real_distribuiton ,which is used by normal_distribution, but replace the distribution, the problem disappears. Also, change _Cilk_for to normal for loop, there is no issue. The only thing I can think of is that _Cilk here somehow corrupted stack data.