[PATCH v2] configure.ac: rework gnu99 ext check to allow clang

[PATCH v2] configure.ac: rework gnu99 ext check to allow clang

[Adrian Ratiu]

It is true that Clang does not support all gnu99 extensions [1],
but not all of them are used in the codebase and over time there
have been code cleanup efforts to improve Clang support.

For example after commit 779c57ea ("readelf: Pull advance_pc()
in file scope") there are no more nested function declarations
and elfutils now builds fine with Clang.

So in the interest of enabling Clang builds we remove the only
remaining blocker: the configure checks for nested functions and
variable length arrays which are also unused.

Considering mixed decls and code is also part of c99 standard,
the entire check becomes redundant and we can just replace
AC_PROG_CC -> AC_PROG_CC_C99.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24964
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
---
 ChangeLog    |  4 ++++
 configure.ac | 35 +----------------------------------
 2 files changed, 5 insertions(+), 34 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6d920b93..6255fe61 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2021-08-10  Adrian Ratiu  <adrian.ratiu@collabora.com>
+
+	* configure.ac (AC_CACHE_CHECK): Rework std=gnu99 check to allow clang.
+
 2021-08-20  Saleem Abdulrasool  <abdulras@google.com>
 
 	* Add AC_CHECK_HEADERS for error.h and err.h.
diff --git a/configure.ac b/configure.ac
index 177bb1a2..76563557 100644
--- a/configure.ac
+++ b/configure.ac
@@ -87,7 +87,7 @@ AS_IF([test "$use_locks" = yes],
 
 AH_TEMPLATE([USE_LOCKS], [Defined if libraries should be thread-safe.])
 
-AC_PROG_CC
+AC_PROG_CC_C99
 AC_PROG_RANLIB
 AC_PROG_YACC
 AM_PROG_LEX
@@ -96,39 +96,6 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
 AC_CHECK_TOOL([READELF], [readelf])
 AC_CHECK_TOOL([NM], [nm])
 
-# We use -std=gnu99 but have explicit checks for some language constructs
-# and GNU extensions since some compilers claim GNU99 support, but don't
-# really support all language extensions. In particular we need
-# Mixed Declarations and Code
-# https://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html
-# Nested Functions
-# https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
-# Arrays of Variable Length
-# https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
-AC_CACHE_CHECK([for gcc with GNU99 support], ac_cv_c99, [dnl
-old_CFLAGS="$CFLAGS"
-CFLAGS="$CFLAGS -std=gnu99"
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([dnl
-int foo (int a)
-{
-  for (int i = 0; i < a; ++i) if (i % 4) break; int s = a; return s;
-}
-
-double bar (double a, double b)
-{
-  double square (double z) { return z * z; }
-  return square (a) + square (b);
-}
-
-void baz (int n)
-{
-  struct S { int x[[n]]; };
-}])],
-		  ac_cv_c99=yes, ac_cv_c99=no)
-CFLAGS="$old_CFLAGS"])
-AS_IF([test "x$ac_cv_c99" != xyes],
-      AC_MSG_ERROR([gcc with GNU99 support required]))
-
 AC_CACHE_CHECK([whether gcc supports __attribute__((visibility()))],
 	ac_cv_visibility, [dnl
 save_CFLAGS="$CFLAGS"
-- 
2.33.0

Re: [PATCH v2] configure.ac: rework gnu99 ext check to allow clang

[Mark Wielaard]

Hi Adrian,

On Mon, 2021-08-30 at 18:43 +0300, Adrian Ratiu wrote:
> It is true that Clang does not support all gnu99 extensions [1],
> but not all of them are used in the codebase and over time there
> have been code cleanup efforts to improve Clang support.
> 
> For example after commit 779c57ea ("readelf: Pull advance_pc()
> in file scope") there are no more nested function declarations
> and elfutils now builds fine with Clang.
> 
> So in the interest of enabling Clang builds we remove the only
> remaining blocker: the configure checks for nested functions and
> variable length arrays which are also unused.
> 
> Considering mixed decls and code is also part of c99 standard,
> the entire check becomes redundant and we can just replace
> AC_PROG_CC -> AC_PROG_CC_C99.
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24964
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>

Thanks for reworking the patch. Pushed.

Thanks,

Mark