MPIR 2.6.0 does not build with clang

[Jean-Pierre Flori]

Dear all,

It seems MPIR 2.6.0 does not build with clang on OSX.
No problems with GCC.
I cannot really provide more details as I don't have access to such arch but this was reported here:
http://trac.sagemath.org/sage_trac/ticket/13137#comment:23

Best,
JP

[Bill Hart]

That doesn't surprise me. Autotools is not designed to ensure that
software builds on a variety of systems or anything outrageous like
that. :-)

I'll add it to the list of things to try and fix for the next release.
Though I don't have access to that platform either.

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mpir-devel/-/xgA6VUTAyZwJ.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.

[leif]

Bill Hart wrote:
> That doesn't surprise me. Autotools is not designed to ensure that
> software builds on a variety of systems or anything outrageous like
> that. :-)
>
> I'll add it to the list of things to try and fix for the next release.
> Though I don't have access to that platform either.

Attached patch (against released 2.6.0's) acinclude.m4 fixes the issue.

With that, 'make checked' passed for me on Linux (different clang 3.x
versions) and even with Apple's old clang 1.7 on MacOS X 10.6.8.


-leif

[Related thread:
http://groups.google.com/group/mpir-devel/browse_thread/thread/7888d9a026432871
]

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Bill Hart]

Thanks. I'll take a look and merge it with the next release.

Bill.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscribe@googlegroups.com.

To post to this group, send email to mpir-...@googlegroups.com.

Visit this group at http://groups.google.com/group/mpir-devel?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.

[Jeroen Demeyer]

On 06/03/2013 01:09 PM, Bill Hart wrote:
> Thanks. I'll take a look and merge it with the next release.

I recommend a different solution, namely using plain malloc() instead of
__builtin_malloc(), or only using __builtin_malloc after testing that it
exists (like you do for __builtin_alloca). That solution is not specific
to any compiler.

[Bill Hart]

Using plain malloc will incur a performance penalty on many versions of gcc, which wouldn't be acceptable for MPIR, but we could look into using __builtin_malloc only after testing its availability.

__builtin_malloc should only be used with GCC, though I am surprised to learn that clang is not 100% compatible on that point.

Anyway, we've started building flint with clang, so MPIR will also be tested against it in future.

Bill.

[Jeroen Demeyer]

On 06/03/2013 01:41 PM, Bill Hart wrote:
> Using plain malloc will incur a performance penalty on many versions of
> gcc

Does that really matter for the configure script?

[Bill Hart]

I've no idea. I will have to look into it carefully. The only use case I am aware of is performance. But that may just be ignorance.

Bill.

[leif]

Not performance, but the brokenness to test might actually be related to
the use of GCC's *built-in* malloc().


-leif

[Jeroen Demeyer]

On 06/03/2013 01:59 PM, leif wrote:
> Not performance, but the brokenness to test might actually be related to
> the use of GCC's *built-in* malloc().

Perhaps, I don't know which GCC-4.3.2 bug this refers to.

If this is the case, it obviously should not be changed to malloc() and
the right thing to do is checking for the existence of __builtin_malloc().

[leif]

#ifdef __clang__
# if __has_builtin(malloc)
# define __builtin_malloc malloc
# else
# define __builtin_malloc malloc
# endif
#endif

;-)

clang's built-in malloc() is just malloc(), not __builtin_malloc(),
available with -fbuiltin (default).

(__has_builtin(malloc) evaluates to false with -fno-builtin.)


(I'm not saying I like this.)

[Jeroen Demeyer]

On 06/03/2013 01:41 PM, Bill Hart wrote:

> we could look into using
> __builtin_malloc only after testing its availability.

I think this is the best solution. Given that you already do this for
__builtin_alloca(), it should not be so hard.

[Bill Hart]

I was thinking of something more like:

#if !(build_on(clang))

just_build(you_stupid_thing)

#else

// what's the problem

#endif

Anyway, thanks for the suggestions. When I get a chance to review I'll insert something like this in the upstream repo.

Bill.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.

[Jeroen Demeyer]

Any chance of finally fixing this bug? It prevents building MPIR (hence
Sage) with Apple XCode 5.0.

[Bill Hart]

I am not actively working on an MPIR release as I have not completed the current flint release and just started a new job in another country.

To be safe, I think it will Christmas before I have time to look at this. Sorry. After this I should become much more active. 

Of course I am happy to merge any sufficiently well-tested patch in my github repo in the mean time.

Bill.

On 1 October 2013 17:30, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

Any chance of finally fixing this bug? It prevents building MPIR (hence Sage) with Apple XCode 5.0.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscribe@googlegroups.com.

To post to this group, send email to mpir-...@googlegroups.com.

Visit this group at http://groups.google.com/group/mpir-devel.

[Jeroen Demeyer]

On 2013-10-01 18:07, Bill Hart wrote:
> I am not actively working on an MPIR release as I have not completed the
> current flint release and just started a new job in another country.
>
> To be safe, I think it will Christmas before I have time to look at
> this. Sorry. After this I should become much more active.
>
> Of course I am happy to merge any sufficiently well-tested patch in my
> github repo in the mean time.

How about simply *removing* the offending test completely? The worst
that could happen is that MPIR tries to build with a broken compiler.
That would be way better than the current situation: refusing to build
with a non-broken compiler.

Jeroen.

[Jeroen Demeyer]

This is the patch that we added for Sage:
http://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.6.0.p3/patches/clang-config.patch

[Bill Hart]

Thanks! I'll look at it carefully when I come to do the MPIR release.

Bill.

On 3 October 2013 10:12, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

This is the patch that we added for Sage:
http://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.6.0.p3/patches/clang-config.patch