The clang compilers from both the 2.9 release and current svn both miscompile the MPFR 3.1.0 library. The resulting binaries on x86_64-apple-darwin11 fail their testsuite with... [tversion] GMP: header 5.0.2, library 5.0.2 [tversion] MPFR tuning parameters from src/x86_64/core2/mparam.h PASS: tversion PASS: tinternals PASS: tinits PASS: tisqrt PASS: tsgn PASS: tcheck PASS: tisnan Error: emin >= emax FAIL: texceptions ../../tests/tset_exp.c:44: MPFR assertion failed: ret == 0 && (__builtin_constant_p (2) && (mpfr_ulong) (2) == 0 ? (mpfr_sgn) (x) : mpfr_cmp_ui_2exp ((x), (2), 0)) == 0 /bin/sh: line 1: 68248 Abort trap: 6 MPFR_QUIET=1 ${dir}$tst FAIL: tset_exp /bin/sh: line 1: 68267 Segmentation fault: 11 MPFR_QUIET=1 ${dir}$tst FAIL: tset PASS: mpf_compat Error in conversion to/from mpz expected 17, got 0.0000000000000000e+00 FAIL: mpfr_compat ../../src/set_str_raw.c:54: MPFR assertion failed: res == 0 /bin/sh: line 1: 68319 Abort trap: 6 MPFR_QUIET=1 ${dir}$tst FAIL: reuse /bin/sh: line 1: 68337 Segmentation fault: 11 MPFR_QUIET=1 ${dir}$tst FAIL: tabs This problem doesn't exist in Apple's Xcode 4.1.1 release but apparently exists in Xcode 4.2 now. These failures are suppressed if MPFR is passed --disable-thread-safe. Comparing the config.log generated against Apple's clang from Xcode 4.1 and llvm.org's 2.9 clang, I see... -checking for TLS support... no +checking for TLS support... yes suggesting that the TLS support in clang svn is buggy.
I would also note that llvm/dragonegg svn can build MPFR 3.1.0 with --enable-thread-safe using FSF gcc 4.6.2svn without regressions.
Jack, Are you able to get us a small test case? I think that MPFR 3.1.0 is GPLv3, which some of us are unable to look at.
Created attachment 7443 [details] example failure from MPFR 3.1.0 testsuite on darwin11
I have uploaded pr11111.tar.bz2 containing the failing testcase for tset_exp from mpfr-3.1.0 compiled with --enable-thread-safe using llvm/clang svn on darwin11. The failure can be reproduced on Lion with by running the showbug shell script... setenv DYLD_LIBRARY_PATH . ./tset_exp ../../tests/tset_exp.c:44: MPFR assertion failed: ret == 0 && (__builtin_constant_p (2) && (mpfr_ulong) (2) == 0 ? (mpfr_sgn) (x) : mpfr_cmp_ui_2exp ((x), (2), 0)) == 0 Abort The source and object file for the failing testcase are also included in the archive.
Something I could compile that shows the issue would help :)
(In reply to comment #5) > Something I could compile that shows the issue would help :) Unfortunately that is entirely non-trivial. In any case, this is starting to smell like a darwin11-specific issue. I can't reproduce the problem on linux. Also, the problem can't be reproduced with either clang 2.9 or clang svn on darwin10 with Xcode 3.2.6. I have also been told that Xcode 4.2 on 10.6 doesn't exhibit this problem but that Xcode 4.2 on 10.7 does.
Darwin10 doesn't support tls so it wouldn't show up there. :(
Interestingly, on darwin11, I can suppress these failures in the MPFR testsuite with clang 2.9 or clang svn building MPFR 3.1.0 if I pass clang the -mmacosx-version-min=10.6. However this also results in configure producing... checking for TLS support... no which is also what clang 2.9 or clang svn produces on darwin10. So the failing TLS support seems to be a new 'feature' in darwin11's sdk.
(In reply to comment #7) > Darwin10 doesn't support tls so it wouldn't show up there. :( Doesn't the fact that this failure doesn't occur with clang svn under x86_64 Fedora 15 linux when building MPFR 3.1.0 (which properly detects the TLS support) suggest that this is really a libSystem bug? If so, shouldn't it be capable of being debugged from the tset_exp binary I provided?
No, tls support doesn't work that way. It's specific code generated that is then assembled and the linker links and dyld fixes up at runtime. It could be anything in that chain.
Filed on radar as Problem ID: 10291355, "Xcode 4.2 miscompiles tls support in MPFR 3.1.0".
I believe this to be fixed with Evan's patch 142550.
(In reply to comment #12) > I believe this to be fixed with Evan's patch 142550. Thanks! This will go into 3.0 once it's verified.
Yes please.
Confirmed fixed at r142553 in llvm/clang trunk svn. Backport of the fix to llvm 3.0 release branch would be nice.
Pulled into 3.0 branch.