Opened 13 years ago
Closed 13 years ago
#33361 closed defect (fixed)
properly fix mpfr to restore clang usage
Reported by: | howarth@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.0.3 |
Keywords: | Cc: | ||
Port: | mpfr |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
The breakage in mpfr with the Xcode 4.2.0 release was mishandled in macports. The actual cause of the breakage was due to a clang bug which was exposed in when tis support was enabled in clang in the Xcode 4.2.0 release. The mpfr 3.1.0 release tickles this bug because it supports tis if present in the compiler. The possible fixes for this problem is either to require Xcode 4.2.1 or later which has this tis code generation bug fixed,
radr://10291355, "Xcode 4.2 miscompiles tls support in MPFR 3.1.0"
by back porting the fix from llvm.org (r142553) for the same issue...
http://llvm.org/bugs/show_bug.cgi?id=11111
The attached Portfile.diff fixes this issue as we have in fink by passing --disable-thread-safe to configure. This has no impact on the build with non-clang compilers as none of them have ever supported tis code generation. For clang, it restores the previous build behavior prior to Xcode 4.2.0 where tis support wasn't available.
Testing on x86_64-apple-darwin11 with Xcode 4.3 shows...
/usr/bin/make check-TESTS [tversion] GMP: header 5.0.4, library 5.0.4 [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 PASS: texceptions PASS: tset_exp PASS: tset PASS: mpf_compat PASS: mpfr_compat PASS: reuse PASS: tabs PASS: tacos PASS: tacosh PASS: tadd PASS: tadd1sp PASS: tadd_d PASS: tadd_ui PASS: tagm PASS: tai PASS: tasin PASS: tasinh PASS: tatan PASS: tatanh PASS: taway PASS: tbuildopt PASS: tcan_round PASS: tcbrt PASS: tcmp PASS: tcmp2 PASS: tcmp_d PASS: tcmp_ld PASS: tcmp_ui PASS: tcmpabs PASS: tcomparisons PASS: tconst_catalan PASS: tconst_euler PASS: tconst_log2 PASS: tconst_pi PASS: tcopysign PASS: tcos PASS: tcosh PASS: tcot PASS: tcoth PASS: tcsc PASS: tcsch PASS: td_div PASS: td_sub PASS: tdigamma PASS: tdim PASS: tdiv PASS: tdiv_d PASS: tdiv_ui PASS: teint PASS: teq PASS: terf PASS: texp PASS: texp10 PASS: texp2 PASS: texpm1 PASS: tfactorial PASS: tfits PASS: tfma PASS: tfmod PASS: tfms PASS: tfprintf PASS: tfrac PASS: tfrexp PASS: tgamma PASS: tget_flt PASS: tget_d PASS: tget_d_2exp PASS: tget_f PASS: tget_ld_2exp SKIP: tget_set_d64 PASS: tget_sj PASS: tget_str PASS: tget_z PASS: tgmpop PASS: tgrandom PASS: thyperbolic PASS: thypot PASS: tinp_str PASS: tj0 PASS: tj1 PASS: tjn PASS: tl2b PASS: tlgamma PASS: tli2 PASS: tlngamma PASS: tlog PASS: tlog10 PASS: tlog1p PASS: tlog2 PASS: tmin_prec PASS: tminmax PASS: tmodf PASS: tmul PASS: tmul_2exp PASS: tmul_d PASS: tmul_ui PASS: tnext PASS: tout_str PASS: toutimpl PASS: tpow PASS: tpow3 PASS: tpow_all PASS: tpow_z PASS: tprintf PASS: trandom PASS: trec_sqrt PASS: tremquo PASS: trint PASS: troot PASS: tround_prec PASS: tsec PASS: tsech PASS: tset_d PASS: tset_f PASS: tset_ld PASS: tset_q PASS: tset_si PASS: tset_sj PASS: tset_str PASS: tset_z PASS: tset_z_exp PASS: tsi_op PASS: tsin PASS: tsin_cos PASS: tsinh PASS: tsinh_cosh PASS: tsprintf PASS: tsqr PASS: tsqrt PASS: tsqrt_ui PASS: tstckintc PASS: tstdint PASS: tstrtofr PASS: tsub PASS: tsub1sp PASS: tsub_d PASS: tsub_ui PASS: tsubnormal PASS: tsum PASS: tswap PASS: ttan PASS: ttanh PASS: ttrunc PASS: tui_div PASS: tui_pow PASS: tui_sub PASS: turandom PASS: tvalist PASS: ty0 PASS: ty1 PASS: tyn PASS: tzeta PASS: tzeta_ui [tversion] GMP: header 5.0.4, library 5.0.4 [tversion] MPFR tuning parameters from src/x86_64/core2/mparam.h PASS: tversion ==================== All 160 tests passed (1 test was not run) ==================== Making check in tune
Attachments (1)
Change History (10)
Changed 13 years ago by howarth@…
Attachment: | Portfile.diff added |
---|
comment:1 Changed 13 years ago by howarth@…
An alternative fix would be to prevent mpfr from building if Xcode 4.2.0 was installed as it is the only Xcode release with this clang bug,
comment:2 Changed 13 years ago by neverpanic (Clemens Lang)
Description: | modified (diff) |
---|---|
Keywords: | devel removed |
Milestone: | MacPorts 2.0.4 |
Please use WikiFormatting and don't set the Milestone field.
comment:3 Changed 13 years ago by neverpanic (Clemens Lang)
Have you verified gcc44, gcc45, and gcc46 build fine on Lion with this patch applied? I'm hesitating to revert r86599, which is a confirmed fix for a nasty and hard-to-debug problem (see #31604), especially since compiling with clang doesn't give us much of an advantage at the moment (although I agree we should always use the default compiler, if possible).
comment:4 follow-up: 9 Changed 13 years ago by howarth@…
I have verified that the gcc45 and gcc46 builds work (gcc44 was already built). IMHO this isn't rocket science. The macports mpfr maintainer should have focused on the fact that mpfr built with clang from Xcode 4.2.0 failed its test suite. This is how the tls code generation bug in clang 3.0svn of Xcode 4.2.0 was detected, fixed in llvm.org's clang 3.0 and then back ported into Xcode 4.2.1's clang. We have been using the --disable-thread-safe approach to workaround the the Xcode 4.2.0 clang bug in fink for four months now without issues in gcc4x build. Again this issue is unique to Xcode 4.2.0 because it both introduced the tis support for clang on Lion and thus exposed the latent tis code generation bug in clang. FYI, I am the fink maintainer for their gcc packages.
comment:5 Changed 13 years ago by howarth@…
Just to be clear, the FSF gcc bootstrap problems seen with mpfr using clang from Xcode 4.2.0 are just a manifestation of the broken mpfr that it builds using the newly available tis support in clang for Lion. The focus should have been entirely on mpfr's test suite failures with clang from Xcode 4.2 in the absence of the--disable-thread-safe configure flag being use. It may have confused you that this issue 'disappeared' (i.e. was fixed) in Xcode 4.2.1 and later so that the tls support was usable in mpfr. Again an alternative fix is to have the Portfile refuse to build on Xcode 4.2.0.
comment:6 Changed 13 years ago by howarth@…
Note that the last option isn't feasible as Xcode 4.2.1 doesn't exist for Snow Leopard (but the bug doesn't exist there because there is no tls kernel support in darwin10 for clang to use). So simply using --disable-thread-safe in mpfr is the cleanest approach. IMHO, the new tls clang support is somewhat experimental as there isn't a lot of code that detects its. The mpfr package was one of the few to do so.
comment:7 Changed 13 years ago by howarth@…
FYI, this is the commit fixing the clang bug...
142550 | evancheng | 2011-10-19 15:22:54 -0700 (Wed, 19 Oct 2011) | 1 line
Fix TLS lowering bug. The CopyFromReg must be glued to the TLSCALL. rdar://10291355
comment:8 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
comment:9 Changed 13 years ago by neverpanic (Clemens Lang)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to howarth@…:
The macports mpfr maintainer should have focused on the fact that mpfr built with clang from Xcode 4.2.0 failed its test suite.
That might not have happened due to the fact, that there currently is no maintainer for mpfr in macports.
Commited in r90220. Thanks for the patch and the explanations.
Portfile.diff with better fix for Xcode 4.2.0 clang code generation issue in mpfr