[BUG/PATCH] C23: old-style lshift_com definitions in configure probes
Nad Ka
french.cryptonad at gmail.com
Sat Sep 5 22:18:13 CEST 2026
Hello,
Follow-up to my earlier report/patch for GNU GMP upstream revision
ab4a7408e2ce.
I independently reproduced the same source-language compatibility result on
x86_64 Linux:
- GCC 14.2, GNU17: old-style definition accepted
- GCC 14.2, GNU23: accepted with -Wold-style-definition warning
- Clang 17, GNU17: accepted
- Clang 17, GNU23: rejected
- prototype form, GNU23: accepted by both GCC and Clang
This strengthens the earlier conclusion that the issue is not established
as AArch64-specific.
The attached x86_64 validation record contains the exact matrix and
diagnostics.
Licensing clarification: acinclude.m4 in GMP is distributed under the GMP
recipient-choice terms (LGPL version 3 or later, or GPL version 2 or
later). My patch contribution is offered under the same terms as the
modified upstream file. The OSARM-authored validation report is offered
under Apache-2.0; any upstream-derived source context retains the GMP
license.
Public finding:
https://github.com/frenchcryptonad-max/linux-arm64-build-findings/tree/main/findings/gmp-tip-ab4a7408e2ce/c23-knr-lshift-com-probes
Public validated fix:
https://github.com/frenchcryptonad-max/linux-arm64-build-findings/tree/main/fixes/gmp-tip-ab4a7408e2ce/c23-knr-lshift-com-probes
Regards,
FrenchCryptoNad
On Sat, 5 Sep 2026 05:29:33 -0700, Nad Ka french.cryptonad at gmail.com wrote:
Hello,
I found a C23 compatibility issue in the current GMP development tip.
Upstream revision:
ab4a7408e2ce
acinclude.m4 contains two mpn_lshift_com configure probes whose
lshift_com functions use old-style K&R definitions.
On AArch64 with Clang in GNU23 mode, the unpatched configure run fails
when these probes are compiled.
Reproducer configuration:
ABI=64
CC=clang
CXX=clang++
CFLAGS=“-O2 -std=gnu23”
–enable-cxx --disable-static --enable-shared
The proposed patch changes only acinclude.m4 and converts the two
lshift_com definitions to modern prototypes.
Validation against the same upstream revision:
GCC GNU23 configure/build/make check: PASS
Clang GNU23 configure/build/make check: PASS
true test failures: 0
The failing unpatched config.log is attached together with the patch,
reproducer and environment information.
Public evidence:
Finding:
https://github.com/frenchcryptonad-max/linux-arm64-build-findings/commit/60de53223aab7cbdc34208ce7c5484a1903cc268
Validated fix:
https://github.com/frenchcryptonad-max/linux-arm64-build-findings/commit/e4dbdd2f5b203f77e2bcac62130af4b41d8bd98a
Regards,
FrenchCryptoNad
-------------- next part --------------
DATE_UTC=2026-09-05T19:58:33Z
ARCH=x86_64
Linux localhost 6.18.35 #1 SMP Mon Aug 31 18:10:37 UTC 2026 x86_64 GNU/Linux
gcc (Debian 14.2.0-19) 14.2.0
clang version 17.0.0 (https://github.com/swiftlang/llvm-project.git 10999b6d034fe318f3d56c83bddb6572593a8bb0)
GCC_KR_GNU17_RC=0
GCC_KR_GNU23_RC=0
CLANG_KR_GNU17_RC=0
CLANG_KR_GNU23_RC=1
GCC_PROTOTYPE_GNU23_RC=0
CLANG_PROTOTYPE_GNU23_RC=0
=== GCC GNU23 ===
/tmp/gmp-knr-c23-540/knr.c: In function 'lshift_com':
/tmp/gmp-knr-c23-540/knr.c:2:1: warning: old-style function definition [-Wold-style-definition]
2 | lshift_com (rp, up, n, cnt)
| ^~~~~~~~~~
=== CLANG GNU23 ===
/tmp/gmp-knr-c23-540/knr.c:2:13: error: unknown type name 'rp'
2 | lshift_com (rp, up, n, cnt)
| ^
/tmp/gmp-knr-c23-540/knr.c:2:17: error: unknown type name 'up'
2 | lshift_com (rp, up, n, cnt)
| ^
/tmp/gmp-knr-c23-540/knr.c:2:21: error: unknown type name 'n'
2 | lshift_com (rp, up, n, cnt)
| ^
/tmp/gmp-knr-c23-540/knr.c:2:24: error: unknown type name 'cnt'; did you mean 'int'?
2 | lshift_com (rp, up, n, cnt)
| ^~~
| int
/tmp/gmp-knr-c23-540/knr.c:2:28: error: expected ';' after top level declarator
2 | lshift_com (rp, up, n, cnt)
| ^
| ;
/tmp/gmp-knr-c23-540/knr.c:7:1: error: expected identifier or '('
7 | {
| ^
6 errors generated.
REPRODUCER=PASS
More information about the gmp-bugs
mailing list