GMP build fails with recent compilers

[Timmmm]

We have the option to automatically download and compile GMP, which is great except that it uses the abomination of autotools. One of the ./configure tests it does compiles this program:

/* 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.  */

#if defined (__GNUC__) && ! defined (__cplusplus)
typedef unsigned long long t1;typedef t1*t2;
void g(){}
void h(){}
static __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;}
void f(){static const struct{t1 n;t1 src[9];t1 want[9];}d[]={{1,{0},{1}},};t1 got[9];int i;
for(i=0;i<1;i++){if(e(got,got,9,d[i].n)==0)h();g(i,d[i].src,d[i].n,got,d[i].want,9);if(d[i].n)h();}}
#else
int dummy;
#endif

int main () { return 0; }

And if it fails it reports that you don't have "a working compiler". The problem is if you have a quite recent version of GCC it defaults to a newer C standard where that program is invalid because they made C a bit less insane:

conftest.c: In function 'f':
conftest.c:12:48: error: too many arguments to function 'g'; expected 0, have 6
   12 | for(i=0;i<1;i++){if(e(got,got,9,d[i].n)==0)h();g(i,d[i].src,d[i].n,got,d[i].want,9);if(d[i].n)h();}}
      |                                                ^ ~
conftest.c:7:6: note: declared here
    7 | void g(){}
      |      ^

I'm not sure what the best option here is. I guess GMP should fix this but given the latest release is over 2 years old we probably shouldn't hold our breaths. It would be really nice to get rid of GMP!

[pmundkur]

I wonder how the distros deal with it.

[arichardson]

Passing -std=c99/c11 to the configure script should keep the old behaviour of int foo() accepting any number of arguments (int foo(...)) instead of the new C23 behaviour of int foo(void).

[jrtc27]

There are multiple issues with that code. static void g() {} is a declarator that is part of a definition, and so () really does mean "no parameters" in old ISO C. It's only for declarations that aren't definitions that you get the weird special historic behaviour, but it's been obsolescent in every version of ISO C (until it was changed to mean the sane thing) so modern compilers will still shout at you (though probably only warn unless you use -Werror, at least?) for doing it.

[jrtc27]

$ echo 'static void foo() {} void bar(void) { foo(1, 2, 3); }' | clang-13 -x c - -o - -S -O2 -std=c11
<stdin>:1:50: warning: too many arguments in call to 'foo'
static void foo() {} void bar(void) { foo(1, 2, 3); }
                                      ~~~        ^
...
$ echo 'static void foo(int x) {} void bar(void) { foo(1, 2, 3); }' | clang-13 -x c - -o - -S -O2 -std=c2x
<stdin>:1:51: error: too many arguments to function call, expected single argument 'x', have 3 arguments
static void foo(int x) {} void bar(void) { foo(1, 2, 3); }
                                           ~~~    ^~~~
<stdin>:1:13: note: 'foo' declared here
static void foo(int x) {} void bar(void) { foo(1, 2, 3); }
            ^
1 error generated.

I guess to be nice to crummy code they let you get away with it pre-C23, but it was still definitely wrong, unlike the declaration-only case.

[arichardson]

There are multiple issues with that code. static void g() {} is a declarator that is part of a definition, and so () really does mean "no parameters" in old ISO C. It's only for declarations that aren't definitions that you get the weird special historic behaviour, but it's been obsolescent in every version of ISO C (until it was changed to mean the sane thing) so modern compilers will still shout at you (though probably only warn unless you use -Werror, at least?) for doing it.

Oh yes I missed that it's actually a definition. In that case I think the best option is to use cmake to patch the gmp sources: https://cmake.org/cmake/help/latest/module/ExternalProject.html#patch-step-options

[jrtc27]

gmp-mirror/gmp@14837ba

Will need to patch the generated configure script with the same thing (unless you want to autoreconf it, but that can be fragile). They also made the same mistake as you in their diagnosis of the problem, even if the conclusion (the patch) doesn't change.

[Timmmm]

I sent an email to the GMP mailing list asking if they'll do a new release with that fix. I guess we can wait a bit to see if they do, and if not probably try and set CCFLAGS=-std=c11 or whatever.

Extra motivation to get rid of GMP anyway! :-D