leif wrote:
> Similar to the issues we already had with clang, and as easy to fix.
>
> See http://trac.sagemath.org/ticket/18247 for details.
Upstream patch attached (only fixes acinclude.m4, not the generated
files, i.e., 'configure').
-leif
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Fix 'configure' test that fails with GCC 5.x just because it now defaults
to standard C inline semantics. (See Sage trac #18247.)
--- mpir-2.7.0/acinclude.m4 2014-09-14 21:59:12.000000000 +0200
+++ mpir-2.7.0/acinclude.m4 2015-04-26 16:26:10.231054407 +0200
@@ -584,6 +584,9 @@
#if defined(__GNUC__) && !defined(__clang__)
typedef unsigned long long t1;typedef t1*t2;
+#if defined(__GNUC_STDC_INLINE__)Â /* e.g. GCC 5.x defaults to this, not __GNUC_GNU_INLINE__ */
+extern
+#endif
__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;}
f(){static const struct{t1 n;t1 src[9];t1 want[9];}d[]={{1,{0},{1}},};t1 got[9];int i;
