Opened 10 years ago

Last modified 7 years ago

#13948 closed defect

Let MPIR build with Clang — at Version 37

Reported by: Jean-Pierre Flori Owned by: Leif Leonhardy
Priority: blocker Milestone: sage-5.12
Component: packages: standard Keywords: spkg mpir clang
Cc: Leif Leonhardy, John Palmieri Merged in:
Authors: Jeroen Demeyer Reviewers:
Report Upstream: Reported upstream. Developers acknowledge bug. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by Jeroen Demeyer)

There are two problems with the MPIR configure script for Clang:

1) It uses __builtin_malloc() which Clang doesn't have, which is an MPIR upstream bug (up to and including MPIR 2.6.0). The spkg simply removes this test.

2) The "long long reliability" test fails with a linker error. This looks like a Clang bug. The spkg changes the test slightly for Clang.

spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.6.0.p3.spkg (spkg diff)

apply 13948_clang_doc.patch (documentation only)

Change History (38)

comment:1 Changed 10 years ago by Leif Leonhardy

Dependencies: #13137
Owner: changed from tbd to Leif Leonhardy

comment:2 Changed 10 years ago by Leif Leonhardy

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

comment:3 in reply to:  2 Changed 9 years ago by Leif Leonhardy

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 thinkTM this is the resulting patch to configure (resulting from patching acinclude.m4 in two places):

  • mpir-2.6.0/configure

     
    51325132  rm -f conftest* a.out b.out a.exe a_out.exe
    51335133  cat >conftest.c <<EOF
    51345134/* 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__)
    51365136int __attribute__((noinline))
    51375137foo(int i)
    51385138{
     
    55885588   Extracted from tests/mpn/t-iord_u.c.  Causes Apple's gcc 3.3 build 1640 and
    55895589   1666 to segfault with e.g., -O2 -mpowerpc64.  */
    55905590
    5591 #ifdef __GNUC__
     5591#if     defined(__GNUC__) && !defined(__clang__)
    55925592typedef unsigned long long t1;typedef t1*t2;
    55935593__inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
    55945594{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;}
     
    63936393  rm -f conftest* a.out b.out a.exe a_out.exe
    63946394  cat >conftest.c <<EOF
    63956395/* 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__)
    63976397int __attribute__((noinline))
    63986398foo(int i)
    63996399{
     
    68496849   Extracted from tests/mpn/t-iord_u.c.  Causes Apple's gcc 3.3 build 1640 and
    68506850   1666 to segfault with e.g., -O2 -mpowerpc64.  */
    68516851
    6852 #ifdef __GNUC__
     6852#if     defined(__GNUC__) && !defined(__clang__)
    68536853typedef unsigned long long t1;typedef t1*t2;
    68546854__inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
    68556855{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 Leif Leonhardy

And that's the corresponding one against upstream's acinclude.m4:

  • mpir-2.6.0/acinclude.m4

     
    480480# first see a simple "main()" works, then go on to other checks
    481481GMP_PROG_CC_WORKS_PART([$1], [])
    482482
    483 GMP_PROG_CC_WORKS_PART_MAIN([$1], [gcc-4.3.2 on 64bit is bad , try -O1 or -fno-strict-aliasing for the flags],
    484 [/* The following aborts with gcc-4.3.2 on a 64bit system which is an unusable compiler */
    485 #if defined(__GNUC__) && !defined(__INTEL_COMPILER)
     483GMP_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__)
    486486int __attribute__((noinline))
    487487foo(int i)
    488488{
     
    566566GMP_PROG_CC_WORKS_PART([$1], [long long reliability test 1],
    567567[/* The following provokes a segfault in the compiler on powerpc-apple-darwin.
    568568   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. */
    570570
    571 #ifdef __GNUC__
     571#if     defined(__GNUC__) && !defined(__clang__)
    572572typedef unsigned long long t1;typedef t1*t2;
    573573__inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
    574574{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 Leif Leonhardy

Description: modified (diff)

comment:6 Changed 9 years ago by Leif Leonhardy

Dependencies: #13137

comment:7 Changed 9 years ago by Jeroen Demeyer

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 Jeroen Demeyer

Description: modified (diff)

comment:9 in reply to:  7 ; Changed 9 years ago by Leif Leonhardy

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 ; Changed 9 years ago by Leif Leonhardy

Report Upstream: N/AReported 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 Leif Leonhardy

Report Upstream: Reported upstream. Developers acknowledge bug.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 Jean-Pierre Flori

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 Jeroen Demeyer

Milestone: sage-5.11sage-5.12

comment:14 Changed 9 years ago by Jeroen Demeyer

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 Jeroen Demeyer

Authors: Jeroen Demeyer
Description: modified (diff)
Report Upstream: Completely fixed; Fix reported upstreamReported upstream. Developers acknowledge bug.

comment:16 Changed 9 years ago by Jeroen Demeyer

Description: modified (diff)

comment:17 Changed 9 years ago by Jeroen Demeyer

Status: newneeds_review

comment:18 Changed 9 years ago by John Palmieri

I'm using OS X 10.8.5 with Xcode 5.0, which means that gcc --version returns

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

The old mpir spkg fails to build for known reasons. The new mpir spkg fails also, though. Log file.

(I also tried unsetting MAKE and it didn't help.)

Last edited 9 years ago by John Palmieri (previous) (diff)

comment:19 Changed 9 years ago by Jeroen Demeyer

Please try the following: extract the spkg and try to "manually" configure it by doing:

$ cd mpir-2.6.0.p3/src
$ ./configure

I'm interested to see the output of that, as well as the resulting config.log file.

comment:20 in reply to:  19 Changed 9 years ago by John Palmieri

Replying to jdemeyer:

Please try the following: extract the spkg and try to "manually" configure it by doing:

$ cd mpir-2.6.0.p3/src
$ ./configure

I'm interested to see the output of that, as well as the resulting config.log file.

This fails almost immediately because it thinks that clang is a broken compiler: config.log.

comment:21 Changed 9 years ago by Jeroen Demeyer

Aah sorry, I meant extract the spkg, apply the patches and then do what you did.

comment:23 Changed 9 years ago by Jeroen Demeyer

Hmm, at first sight looks like a genuine compiler bug, but that's hard to say from here...

comment:24 Changed 9 years ago by Jeroen Demeyer

Could you try the same (i.e. manual ./configure) with export CC=clang?

comment:25 Changed 9 years ago by John Palmieri

With export CC=clang: config.log and configure output.

By the way, running make seems to succeed after all of these manual runs of ./configure. Once I set CFLAGS as Sage does -- that is,

export CFLAGS="-m32 -O2 -fomit-frame-pointer -mtune=corei7-avx -march=corei7-avx  -g"

then do ./configure and make, it fails. Remove the -m32 flag and it works again. Can we just remove -m32 in the spkg?

comment:26 Changed 9 years ago by Jeroen Demeyer

It seems that gcc is identical to clang, so that didn't make a difference.

Can we just remove -m32 in the spkg?

There is no -m32 in the spkg. The problem is that -m64 simply doesn't work, so MPIR's configure falls back to -m32.

comment:27 in reply to:  25 Changed 9 years ago by Jeroen Demeyer

Replying to jhpalmieri:

Remove the -m32 flag and it works again.

Exactly what does "it" refer to here? Did you manage to ./configure MPIR as 64-bit?

Last edited 9 years ago by Jeroen Demeyer (previous) (diff)

comment:28 Changed 9 years ago by John Palmieri

I mean that if I do

export CFLAGS="-O2 -fomit-frame-pointer -mtune=corei7-avx -march=corei7-avx  -g"
./configure
make

it finishes without error. (I haven't tried a full Sage build on top of this, of course.) If CFLAGS also includes -m32, then make fails.

In the spkg, we could have some code like

  • spkg-install

    diff --git a/spkg-install b/spkg-install
    a b  
    275275echo "  ABI:     $user_abi"
    276276echo "  (CPP, CPPFLAGS, CXX and CXXFLAGS are listed below; these don't get modified.)"
    277277
     278# Fix bug with Xcode 5.0 on Darwin: mpir doesn't build using the -m32
     279# flag with the gcc from this version of Xcode.
     280if [ blah ]; then        # using Xcode 5.0 on Darwin
     281    mpir_cflags=...      # remove -m32 from $mpir_cflags
     282fi
     283
    278284# Finally: use MPIR's flags, plus those required by Sage for the
    279285# package to build properly, plus those specified by the user.
    280286CFLAGS="$mpir_cflags $required_cflags $user_cflags"

I have no idea if this is actually a good idea, though.

comment:29 Changed 9 years ago by John Palmieri

Now I have tried a full Sage build on top of this, and the build finishes. I guess that isn't too surprising, because mpir gets rebuilt with Sage's GCC anyway.

I'll try again with a more carefully constructed spkg, and I'll also run the full test suite. Here's my actual proposed patch to spkg-install:

  • spkg-install

    diff --git a/spkg-install b/spkg-install
    a b  
    275275echo "  ABI:     $user_abi"
    276276echo "  (CPP, CPPFLAGS, CXX and CXXFLAGS are listed below; these don't get modified.)"
    277277
     278# Fix bug with Xcode 5.0 or later on Darwin: mpir doesn't build using
     279# the -m32 flag with the gcc from this version of Xcode, so remove
     280# -m32 from CFLAGS.
     281if [ "$UNAME" = "Darwin" ]; then
     282    # Xcode version detection, etc., taken from spkg/base/prereq
     283    XCODE_VERS=`xcodebuild -version 2> /dev/null | grep Xcode | sed -e 's/[A-Za-z ]//g'`
     284    if [ -z $XCODE_VERS ]; then
     285        XCODE_VERS="2"
     286    fi
     287    XCODE_VERS_MAJOR=`echo $XCODE_VERS | cut '-d.' -f1`
     288    if [ $XCODE_VERS_MAJOR -gt 4 ]; then
     289        mpir_cflags=`echo $mpir_cflags | sed 's/-m32//'` # remove -m32
     290    fi
     291fi
     292
    278293# Finally: use MPIR's flags, plus those required by Sage for the
    279294# package to build properly, plus those specified by the user.
    280295CFLAGS="$mpir_cflags $required_cflags $user_cflags"

comment:30 Changed 9 years ago by John Palmieri

I used an spkg with this patch, took an otherwise clean tarball for 5.12.rc0, did export SAGE_CHECK=yes. Then make ptestlong was completely successful.

comment:31 Changed 9 years ago by Jeroen Demeyer

What does

$ gcc -E -dM -x c /dev/null |grep -i clang

say on that machine?

Instead of fiddling with CFLAGS, I propose to try to "fix" the test causing the 64-bit build to fail.

Last edited 9 years ago by Jeroen Demeyer (previous) (diff)

comment:32 Changed 9 years ago by Jeroen Demeyer

I prepared a new version of the spkg with a simple fix, can you test it? Simply try to install the spkg normally through Sage. If that fails, send me the file configure-empty.log

Last edited 9 years ago by Jeroen Demeyer (previous) (diff)

Changed 9 years ago by Jeroen Demeyer

Attachment: mpir-2.6.0.p3.diff added

comment:33 Changed 9 years ago by Jeroen Demeyer

Description: modified (diff)

comment:34 Changed 9 years ago by Jeroen Demeyer

Description: modified (diff)

comment:35 in reply to:  31 ; Changed 9 years ago by John Palmieri

Replying to jdemeyer:

What does

$ gcc -E -dM -x c /dev/null |grep -i clang

say on that machine?

gcc -E -dM -x c /dev/null |grep -i clang
#define __VERSION__ "4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.76)"
#define __clang__ 1
#define __clang_major__ 5
#define __clang_minor__ 0
#define __clang_patchlevel__ 0
#define __clang_version__ "5.0 (clang-500.2.76)"

The new spkg seems to work. I'm trying a full Sage build to make sure.

comment:36 in reply to:  35 Changed 9 years ago by Jeroen Demeyer

Replying to jhpalmieri:

gcc -E -dM -x c /dev/null |grep -i clang
#define __VERSION__ "4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.76)"
#define __clang__ 1
#define __clang_major__ 5
#define __clang_minor__ 0
#define __clang_patchlevel__ 0
#define __clang_version__ "5.0 (clang-500.2.76)"

This confirms my suspicion that gcc really is Clang.

comment:37 Changed 9 years ago by Jeroen Demeyer

Description: modified (diff)
Note: See TracTickets for help on using tickets.