Opened 10 years ago
Last modified 7 years ago
#13948 closed defect
Let MPIR build with Clang — at Version 15
Reported by: | jpflori | Owned by: | leif |
---|---|---|---|
Priority: | blocker | Milestone: | sage-5.12 |
Component: | packages: standard | Keywords: | spkg mpir clang |
Cc: | leif, jhpalmieri | Merged in: | |
Authors: | Jeroen Demeyer | Reviewers: | |
Report Upstream: | Reported upstream. Developers acknowledge bug. | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
The problem with clang
is that simply MPIR's configure
bails out (because it uses __builtin_malloc()
which Clang doesn't have), which is an upstream bug (up to and including MPIR 2.6.0).
This spkg simply removes the offending test:
spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.6.0.p2.spkg
Change History (15)
comment:1 Changed 10 years ago by
- Dependencies set to #13137
- Owner changed from tbd to leif
comment:2 follow-up: ↓ 3 Changed 9 years ago by
comment:3 in reply to: ↑ 2 Changed 9 years ago by
Replying to leif:
(I do have a trivial patch to
acinclude.m4
to make MPIR configure [and of course build and pass its test suite] withclang
. Haven't yet submitted it upstream either IIRC.)
I thinkTM this is the resulting patch to configure
(resulting from patching acinclude.m4
in two places):
-
mpir-2.6.0/configure
5132 5132 rm -f conftest* a.out b.out a.exe a_out.exe 5133 5133 cat >conftest.c <<EOF 5134 5134 /* The following aborts with gcc-4.3.2 on a 64bit system which is an unusable compiler */ 5135 #if defined(__GNUC__) && !defined(__INTEL_COMPILER) 5135 #if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__) 5136 5136 int __attribute__((noinline)) 5137 5137 foo(int i) 5138 5138 { … … 5588 5588 Extracted from tests/mpn/t-iord_u.c. Causes Apple's gcc 3.3 build 1640 and 5589 5589 1666 to segfault with e.g., -O2 -mpowerpc64. */ 5590 5590 5591 #if def __GNUC__5591 #if defined(__GNUC__) && !defined(__clang__) 5592 5592 typedef unsigned long long t1;typedef t1*t2; 5593 5593 __inline__ t1 e(t2 rp,t2 up,int n,t1 v0) 5594 5594 {t1 c,x,r;int i;if(v0){c=1;for(i=1;i<n;i++){x=up[i];r=x+1;rp[i]=r;}}return c;} … … 6393 6393 rm -f conftest* a.out b.out a.exe a_out.exe 6394 6394 cat >conftest.c <<EOF 6395 6395 /* The following aborts with gcc-4.3.2 on a 64bit system which is an unusable compiler */ 6396 #if defined(__GNUC__) && !defined(__INTEL_COMPILER) 6396 #if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__) 6397 6397 int __attribute__((noinline)) 6398 6398 foo(int i) 6399 6399 { … … 6849 6849 Extracted from tests/mpn/t-iord_u.c. Causes Apple's gcc 3.3 build 1640 and 6850 6850 1666 to segfault with e.g., -O2 -mpowerpc64. */ 6851 6851 6852 #if def __GNUC__6852 #if defined(__GNUC__) && !defined(__clang__) 6853 6853 typedef unsigned long long t1;typedef t1*t2; 6854 6854 __inline__ t1 e(t2 rp,t2 up,int n,t1 v0) 6855 6855 {t1 c,x,r;int i;if(v0){c=1;for(i=1;i<n;i++){x=up[i];r=x+1;rp[i]=r;}}return c;}
comment:4 Changed 9 years ago by
And that's the corresponding one against upstream's acinclude.m4
:
-
mpir-2.6.0/acinclude.m4
480 480 # first see a simple "main()" works, then go on to other checks 481 481 GMP_PROG_CC_WORKS_PART([$1], []) 482 482 483 GMP_PROG_CC_WORKS_PART_MAIN([$1], [gcc-4.3.2 on 64 bit is bad, try -O1 or -fno-strict-aliasing for the flags],484 [/* The following aborts with gcc-4.3.2 on a 64 bit system which is an unusable compiler */485 #if defined(__GNUC__) && !defined(__INTEL_COMPILER) 483 GMP_PROG_CC_WORKS_PART_MAIN([$1], [gcc-4.3.2 on 64-bit is bad, try -O1 or -fno-strict-aliasing for the flags], 484 [/* The following aborts with gcc-4.3.2 on a 64-bit system which is an unusable compiler */ 485 #if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__) 486 486 int __attribute__((noinline)) 487 487 foo(int i) 488 488 { … … 566 566 GMP_PROG_CC_WORKS_PART([$1], [long long reliability test 1], 567 567 [/* The following provokes a segfault in the compiler on powerpc-apple-darwin. 568 568 Extracted from tests/mpn/t-iord_u.c. Causes Apple's gcc 3.3 build 1640 and 569 1666 to segfault with e.g., -O2 -mpowerpc64.*/569 1666 to segfault with, e.g., -O2 -mpowerpc64. */ 570 570 571 #if def __GNUC__571 #if defined(__GNUC__) && !defined(__clang__) 572 572 typedef unsigned long long t1;typedef t1*t2; 573 573 __inline__ t1 e(t2 rp,t2 up,int n,t1 v0) 574 574 {t1 c,x,r;int i;if(v0){c=1;for(i=1;i<n;i++){x=up[i];r=x+1;rp[i]=r;}}return c;}
comment:5 Changed 9 years ago by
- Description modified (diff)
comment:6 Changed 9 years ago by
- Dependencies #13137 deleted
comment:7 follow-up: ↓ 9 Changed 9 years ago by
Leif: do you plan to make a proper spkg? Have you reported it upstream? (If both answers are "NO", that's fine, I can do it).
comment:8 Changed 9 years ago by
- Description modified (diff)
comment:9 in reply to: ↑ 7 ; follow-up: ↓ 10 Changed 9 years ago by
Replying to jdemeyer:
Leif: do you plan to make a proper spkg?
Plan to: Yes.
Right now: No. (So feel free to do so.)
Have you reported it upstream?
Yes, quite a while ago (on mpir-devel).
I also reported how to fix it, but haven't (yet) submitted the "final" acinclude.m4
patch above IIRC.
(I was actually going to ask Bill about the MPIR release schedule, also because of this.)
comment:10 in reply to: ↑ 9 ; follow-up: ↓ 11 Changed 9 years ago by
- Report Upstream changed from N/A to Reported upstream. Developers acknowledge bug.
Replying to leif:
Replying to jdemeyer:
Have you reported it upstream?
Yes, quite a while ago (on mpir-devel).
http://groups.google.com/group/mpir-devel/browse_thread/thread/7888d9a026432871#
(See also http://groups.google.com/group/mpir-devel/browse_thread/thread/c9d70a195f846258#.)
I also reported how to fix it, but haven't (yet) submitted the "final"
acinclude.m4
patch above IIRC.
Yep.
comment:11 in reply to: ↑ 10 Changed 9 years ago by
- Report Upstream changed from Reported upstream. Developers acknowledge bug. to Completely fixed; Fix reported upstream
Replying to leif:
I also reported how to fix it, but haven't (yet) submitted the "final"
acinclude.m4
patch above IIRC.
Patch now submitted upstream.
comment:12 Changed 9 years ago by
Any chance to get an spkg to review? Or should I begin working on Cygwin64 support without fearing a future rebase?
comment:13 Changed 9 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:14 Changed 9 years ago by
I am going to move forward on this and simply make a spkg which completely removes the offending test.
comment:15 Changed 9 years ago by
- Description modified (diff)
- Report Upstream changed from Completely fixed; Fix reported upstream to Reported upstream. Developers acknowledge bug.
Pinging myself... ;-)
(I do have a trivial patch to
acinclude.m4
to make MPIR configure [and of course build and pass its test suite] withclang
. Haven't yet submitted it upstream either IIRC.)