From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10791 invoked by alias); 21 Oct 2014 18:35:50 -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 10670 invoked by uid 48); 21 Oct 2014 18:35:46 -0000 From: "vbraun at physics dot upenn.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/63610] New: OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1 Date: Tue, 21 Oct 2014 18:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vbraun at physics dot upenn.edu 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-10/txt/msg01611.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 Bug ID: 63610 Summary: OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vbraun at physics dot upenn.edu Trying to bulid gcc on OSX 10.10 with the Apple command line tools. So I first compile MPIR/MPFR/MPC with clang, then bootstrap gcc. This works so far (the patch from PR target/61407 for dealing with the version parsing is applied). But the newly-built gcc can't successfully compile MPIR, and I'm getting the testsuite failures below. The failure is only present if I both enable C++ (--enable-cxx in the MPIR configure), build a shared library, and set optimization to -O0 or -O1 (whereas -O2 works). Steps to reproduce (in the MPIR 2.6.0 source directory): $ export CFLAGS=-O0 $ ./configure --enable-cxx --disable-static $ make $ make check [...] make check-TESTS /bin/sh: line 1: 59465 Segmentation fault: 11 "$tst" > t-bswap.log-t 2>&1 FAIL: t-bswap PASS: t-constants PASS: t-count_zeros PASS: t-gmpmax PASS: t-hightomask PASS: t-modlinv PASS: t-parity /bin/sh: line 1: 59648 Segmentation fault: 11 "$tst" > t-popc.log-t 2>&1 FAIL: t-popc PASS: t-sub ============================================================= 2 of 9 tests failed See tests/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ ============================================================= make[5]: *** [test-suite.log] Error 1 make[4]: *** [check-TESTS] Error 2 make[3]: *** [check-am] Error 2 make[2]: *** [check-recursive] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 Apart from the segfault, there is nothing in the log (full log attached) that indicates a failure. It seems that lower optimization leaves something in the binary that interacts badly with C++ support, but I don't have a better testcase. It is not just in MPIR, I get similar looking segfaults in other shared libraries when C++ is involved. Others have been able to reproduce the same testsuite failure on OSX. Works fine on Linux x86_64 with same versions of everything (except that gcc is used to bootstrap, of course). Stack backtrace from the t-popc test (full gdb log attached): #0 0x00007fff86172432 in __block_descriptor_tmp227 () from /usr/lib/system/libdyld.dylib #1 0x00007fff5fbffa80 in ?? () #2 0x00000001000ca0d0 in ?? () from /Users/vbraun/Code/mpir-2.6.0/.libs/libmpir.11.dylib #3 0x000000000000011d in ?? () #4 0x00000001000223c1 in __gmp_randget_mt (rstate=0x7fff5fbffb60, dest=0x7fff5fbffab0, nbits=32) at randmt.c:256 #5 0x000000010006d81d in ?? () from /Users/vbraun/Code/mpir-2.6.0/.libs/libmpir.11.dylib #6 0x000000010006d71c in ?? () from /Users/vbraun/Code/mpir-2.6.0/.libs/libmpir.11.dylib #7 0x0000000100000f8c in main () at t-popc.c:60 (gdb) frame 4 #4 0x00000001000223c1 in __gmp_randget_mt (rstate=0x7fff5fbffb60, dest=0x7fff5fbffab0, nbits=32) at randmt.c:256 256 NEXT_RANDOM; The NEXT_RANDOM macro is just the next step of MPIR's Mersenne twister, it only does elementary bit operations on the state variable. It also only fails after the 70th iteration of the outermost loop. Successive runs always fail in the same __block_descriptor_tmp227. The other failing testcase t-bswap also segfaults in the Mersenne twister.