Let MPIR build with Clang

[jpflori]

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

[leif]

Pinging myself... ;-)

(I do have a trivial patch to acinclude.m4 to make MPIR configure [and of course build and pass its test suite] with clang. Haven't yet submitted it upstream either IIRC.)

[leif]

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] with clang. Haven't yet submitted it upstream either IIRC.)

I think^TM 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
   cat >conftest.c <<EOF
 /* The following aborts with gcc-4.3.2 on a 64bit system which is an unusable compiler */
-#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
+#if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__)
 int __attribute__((noinline))
 foo(int i)
 {
@@ -5588 +5588 @@
    Extracted from tests/mpn/t-iord_u.c.  Causes Apple's gcc 3.3 build 1640 and
    1666 to segfault with e.g., -O2 -mpowerpc64.  */
 
-#ifdef __GNUC__
+#if     defined(__GNUC__) && !defined(__clang__)
 typedef unsigned long long t1;typedef t1*t2;
 __inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
 {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
   cat >conftest.c <<EOF
 /* The following aborts with gcc-4.3.2 on a 64bit system which is an unusable compiler */
-#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
+#if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__)
 int __attribute__((noinline))
 foo(int i)
 {
@@ -6849 +6849 @@
    Extracted from tests/mpn/t-iord_u.c.  Causes Apple's gcc 3.3 build 1640 and
    1666 to segfault with e.g., -O2 -mpowerpc64.  */
 
-#ifdef __GNUC__
+#if     defined(__GNUC__) && !defined(__clang__)
 typedef unsigned long long t1;typedef t1*t2;
 __inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
 {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;}

[leif]

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
 GMP_PROG_CC_WORKS_PART([$1], [])
 
-GMP_PROG_CC_WORKS_PART_MAIN([$1], [gcc-4.3.2 on 64bit is bad , try -O1 or -fno-strict-aliasing for the flags],
-[/* The following aborts with gcc-4.3.2 on a 64bit system which is an unusable compiler */
-#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
+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],
+[/* The following aborts with gcc-4.3.2 on a 64-bit system which is an unusable compiler */
+#if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__)
 int __attribute__((noinline))
 foo(int i)
 {
@@ -566 +566 @@
 GMP_PROG_CC_WORKS_PART([$1], [long long reliability test 1],
 [/* The following provokes a segfault in the compiler on powerpc-apple-darwin.
    Extracted from tests/mpn/t-iord_u.c.  Causes Apple's gcc 3.3 build 1640 and
-   1666 to segfault with e.g., -O2 -mpowerpc64.  */
+   1666 to segfault with, e.g., -O2 -mpowerpc64. */
 
-#ifdef __GNUC__
+#if     defined(__GNUC__) && !defined(__clang__)
 typedef unsigned long long t1;typedef t1*t2;
 __inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
 {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;}

[jdemeyer]

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).

[leif]

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.)

[leif]

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.

[leif]

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.

[jpflori]

Any chance to get an spkg to review? Or should I begin working on Cygwin64 support without fearing a future rebase?

[jdemeyer]

I am going to move forward on this and simply make a spkg which completely removes the offending test.