Re: [PATCH] AC_PROG_CC_C11: new macro, which AC_PROG_CC_STDC now defaults to

[Paul Eggert]

On 09/21/2012 08:32 AM, Jim Meyering wrote:
> Here's what happens with diffutils:

Hah!  That's what I get for wading into this mess.
But thanks for catching that; fix below.

On 09/21/2012 01:18 AM, Andrew W. Nosenko wrote:
> Assuming that AC_PROG_CC_C99 deprecated and then removed, how I
> supposed to express "give me c99 or higher compiler or raise error if
> there only c89 or lower compiler found"?

I suppose one can look at the variables that AC_PROG_CC sets.  But I'm
not sure we should be pushing this use case that hard, to be honest.
If a program really needs C99, the compilation will fail anyway, and
there's not much that a 'configure' script can do about it.

On 09/21/2012 02:01 AM, Adrian Bunk wrote:

> Any other changes of C89/C99 behaviour that might affect code in 
> packages using autoconf?

"gets" is the only one that comes to mind.  And it's being deprecated
even in pre-C11 mode anyway, for obvious reasons, so it's no big deal.

> What if e.g. gcc 4.7 has some bug in C11 mode that would be
> triggered by several packages?

Anything's possible, I suppose.  But C11 mode doesn't really
do that much (unless you also specify -pedantic, which nobody should)
-- i.e., the C11 features are all there anyway.  So I don't think
it'll be much of a problem.  C11 is much better than C99 was, in
the sense that a compiler can support C11 features while still
conforming to C99.  (Other than "gets".)

> Marking AC_PROG_CC_C89/AC_PROG_CC_C99/AC_PROG_CC_STDC as obsolete
> (and turning them into aliases for AC_PROG_CC) is an option, and the 
> more I think about it, it seems like the only option where trying to 
> set the compiler into the highest possible mode in AC_PROG_CC makes sense.

Yes, on further thought I'm inclined to agree.  Also, it's a lot
simpler.  Also, it fixes Jim's bug.  There's a lot to like.
Please see the patch below, which I've pushed.  Further
comments welcome.


>From f7fe375b26f39d0a6624ad9a6c532d9361a3226b Mon Sep 17 00:00:00 2001
From: Paul Eggert <address@hidden>
Date: Fri, 21 Sep 2012 19:19:54 -0700
Subject: [PATCH] AC_PROG_CC_C89, AC_PROG_CC_C99: now obsolete; defer to
 AC_PROG_CC

* NEWS:
* doc/autoconf.texi (C Compiler, Running the Preprocessor)
(Limitations of Usual Tools, Present But Cannot Be Compiled)
(Obsolete Macros):
Document the changes described below.
* lib/autoconf/c.m4 (_AC_PROG_CC_FORCE_VERSION): Remove.
(AC_PROG_CC_C89, AC_PROG_CC_C99, AC_PROG_CC_STDC):
Just do AC_PROG_CC, but mark as obsolete.  This replaces my recent
ill-advised attempt to let AC_PROG_CC_C89 and AC_PROG_CC_C99 downgrade
the version of C supported.
* doc/autoconf.texi (Limitations of Usual Tools, Volatile Objects):
Document C11 more accurately.  In some cases this involves removing
some details about 'volatile', alas, since C11 changed this stuff.
Again.
---
 NEWS              |   8 ++--
 doc/autoconf.texi | 125 ++++++++++++++++++++++--------------------------------
 lib/autoconf/c.m4 |  41 ++++++------------
 3 files changed, 65 insertions(+), 109 deletions(-)

diff --git a/NEWS b/NEWS
index 7db1c82..8b35cb8 100644
--- a/NEWS
+++ b/NEWS
@@ -11,12 +11,10 @@ GNU Autoconf NEWS - User visible changes.
 ** Macros
 
 - AC_PROG_CC now prefers C11 if available, falling back on C99 and
-  then on C89 as before.  (There is no AC_PROG_CC_C11 macro, as no
-  need for one has been identified.)
+  then on C89 as before.
 
-- It is now documented that AC_PROG_CC_C89 and AC_PROG_CC_C99
-  interfere with each other and with AC_PROG_CC.  Applications should
-  normally use AC_PROG_CC.
+- AC_PROG_CC_STDC, AC_PROG_CC_C89, AC_PROG_CC_C99 have been marked as obsolete.
+  Applications should use AC_PROG_CC.
 
 - AC_FUNC_VFORK now checks for the signal-handling bug in Solaris 2.4 'vfork'.
   Formerly, it ignored this bug, so that Emacs could use some tricky
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 86b31ee..08082aa 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7256,6 +7256,18 @@ After calling this macro you can check whether the C 
compiler has been
 set to accept Standard C; if not, the shell variable
 @code{ac_cv_prog_cc_stdc} is set to @samp{no}.
 
+When attempting to add compiler options, prefer extended functionality
+modes over strict conformance modes.  Test for C11 support by checking
+for @code{_Alignas}, @code{_Alignof}, @code{_Noreturn},
address@hidden, UTF-8 string literals, duplicate @code{typedef}s,
+and anonymous structures and unions.  Test for C99 support by checking
+for @code{_Bool}, @code{//} comments, flexible array members,
address@hidden, signed and unsigned @code{long long int}, mixed code and
+declarations, named initialization of structs, @code{restrict},
address@hidden, varargs macros, variable declarations in @code{for}
+loops, and variable length arrays.  Test for C89 support by checking for
+function prototypes.
+
 If using the GNU C compiler, set shell variable @code{GCC} to
 @samp{yes}.  If output variable @code{CFLAGS} was not already set, set
 it to @option{-g -O2} for the GNU C compiler (@option{-O2} on systems
@@ -7323,51 +7335,6 @@ features.  To check for characteristics not listed here, 
use
 @code{AC_COMPILE_IFELSE} (@pxref{Running the Compiler}) or
 @code{AC_RUN_IFELSE} (@pxref{Runtime}).
 
address@hidden AC_PROG_CC_C89
address@hidden
address@hidden prog_cc_c89
-If the C compiler is not in ANSI C89 (ISO C90) mode by
-default, try to add an option to output variable @code{CC} to make it
-so.  This macro tries various options that select ANSI C89 on
-some system or another, preferring extended functionality modes over
-strict conformance modes.  It considers the compiler to be in
-ANSI C89 mode if it handles function prototypes correctly.
-
-After calling this macro you can check whether the C compiler has been
-set to accept ANSI C89; if not, the shell variable
address@hidden is set to @samp{no}.
-
-This macro is rarely needed.  It should be used only if your application
-requires C89 and will not work in later C versions.  Typical applications
-should use @code{AC_PROG_CC} instead.
address@hidden defmac
-
address@hidden AC_PROG_CC_C99
address@hidden
address@hidden prog_cc_c99
-If the C compiler is not in C99 mode by default, try to add an
-option to output variable @code{CC} to make it so.  This macro tries
-various options that select C99 on some system or another, preferring
-extended functionality modes over strict conformance modes.  It
-considers the compiler to be in C99 mode if it handles @code{_Bool},
address@hidden//} comments, flexible array members, @code{inline}, signed and
-unsigned @code{long long int}, mixed code and declarations, named
-initialization of structs,
address@hidden, @code{va_copy}, varargs macros, variable declarations
-in @code{for} loops, and variable length arrays.
-
-After calling this macro you can check whether the C compiler has been
-set to accept C99; if not, the shell variable
address@hidden is set to @samp{no}.
-
-This macro is rarely needed.  It should be used only if your application
-requires C99 and will not work in later C versions.  Typical applications
-should use @code{AC_PROG_CC} instead.
-
-There is no @code{AC_PROG_CC_C11} macro, as no need for one has been
-identified.
address@hidden defmac
-
 @defmac AC_C_BACKSLASH_A
 @acindex{C_BACKSLASH_A}
 @cvindex HAVE_C_BACKSLASH_A
@@ -9311,19 +9278,19 @@ AC_PREPROC_IFELSE(
 @end example
 
 @noindent
-results in:
+might result in:
 
 @example
 checking for gcc... gcc
-checking for C compiler default output file name... a.out
 checking whether the C compiler works... yes
-checking whether we are cross compiling... no
+checking for C compiler default output file name... a.out
 checking for suffix of executables...
+checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
-checking for gcc option to accept ISO C89... none needed
-checking how to run the C preprocessor... gcc -E
+checking for gcc option to accept ISO C11... -std=gnu11
+checking how to run the C preprocessor... gcc -std=gnu11 -E
 OK
 @end example
 
@@ -18637,7 +18604,8 @@ The default executable, produced by @samp{cc foo.c}, 
can be
 The C compiler's traditional name is @command{cc}, but other names like
 @command{gcc} are common.  Posix 1003.1-2001 and 1003.1-2008 specify the
 name @command{c99}, but older Posix editions specified
address@hidden and anyway these standard names are rarely used in
address@hidden, future POSIX standards will likely specify
address@hidden, and anyway these standard names are rarely used in
 practice.  Typically the C compiler is invoked from makefiles that use
 @samp{$(CC)}, so the value of the @samp{CC} make variable selects the
 compiler name.
@@ -21606,28 +21574,25 @@ objects are ordinary.
 
 Even when accessing objects defined with a volatile type,
 the C standard allows only
-extremely limited signal handlers: the behavior is undefined if a signal
+extremely limited signal handlers: in C99 the behavior is undefined if a signal
 handler reads any nonlocal object, or writes to any nonlocal object
 whose type is not @code{sig_atomic_t volatile}, or calls any standard
-library function other than @code{abort}, @code{signal}, and (if C99 or later)
+library function other than @code{abort}, @code{signal}, and
 @code{_Exit}.  Hence C compilers need not worry about a signal handler
-disturbing ordinary computation, unless the computation accesses a
address@hidden volatile} lvalue that is not a local variable.
-(There is an obscure exception for accesses via a pointer to a volatile
-character, since it may point into part of a @code{sig_atomic_t
-volatile} object.)  Posix
-adds to the list of library functions callable from a portable signal
-handler, but otherwise is like the C standard in this area.
+disturbing ordinary computation.  C11 and Posix allow some additional
+behavior in a portable signal handler, but are still quite restrictive.
 
 Some C implementations allow memory-access optimizations within each
 translation unit, such that actual behavior agrees with the behavior
 required by the standard only when calling a function in some other
 translation unit, and a signal handler acts like it was called from a
-different translation unit.  The C standard hints that in these
+different translation unit.  The C99 standard hints that in these
 implementations, objects referred to by signal handlers ``would require
 explicit specification of @code{volatile} storage, as well as other
 implementation-defined restrictions.''  But unfortunately even for this
 special case these other restrictions are often not documented well.
+This area was significantly changed in C11, and eventually implementations
+will probably head in the C11 direction, but this will take some time.
 @xref{Volatiles, , When is a Volatile Object Accessed?, gcc, Using the
 GNU Compiler Collection (GCC)}, for some
 restrictions imposed by GCC.  @xref{Defining Handlers, ,
@@ -23656,6 +23621,16 @@ Replaced by @code{AC_TYPE_PID_T} 
(@pxref{AC_TYPE_PID_T}).
 Replaced by @code{AC_PREFIX_PROGRAM} (@pxref{AC_PREFIX_PROGRAM}).
 @end defmac
 
address@hidden AC_PROG_CC_C89
address@hidden
+Now done by @code{AC_PROG_CC} (@pxref{AC_PROG_CC}).
address@hidden defmac
+
address@hidden AC_PROG_CC_C99
address@hidden
+Now done by @code{AC_PROG_CC} (@pxref{AC_PROG_CC}).
address@hidden defmac
+
 @defmac AC_PROG_CC_STDC
 @acindex{PROG_CC_STDC}
 Now done by @code{AC_PROG_CC} (@pxref{AC_PROG_CC}).
@@ -25939,19 +25914,19 @@ $ @kbd{cat configure.ac}
 AC_INIT([Example], [1.0], [bug-example@@example.org])
 AC_CHECK_HEADERS([pi.h])
 $ @kbd{autoconf -Wall}
-$ @kbd{./configure}
+$ @kbd{./configure CPPFLAGS='-I.'}
 checking for gcc... gcc
-checking for C compiler default output file name... a.out
 checking whether the C compiler works... yes
-checking whether we are cross compiling... no
+checking for C compiler default output file name... a.out
 checking for suffix of executables...
+checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
-checking for gcc option to accept ISO C89... none needed
-checking how to run the C preprocessor... gcc -E
-checking for grep that handles long lines and -e... grep
-checking for egrep... grep -E
+checking for gcc option to accept ISO C11... -std=gnu11
+checking how to run the C preprocessor... gcc -std=gnu11 -E
+checking for grep that handles long lines and -e... /usr/bin/grep
+checking for egrep... /usr/bin/grep -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
@@ -25969,10 +25944,10 @@ configure: WARNING: pi.h:     check for missing 
prerequisite headers?
 configure: WARNING: pi.h: see the Autoconf documentation
 configure: WARNING: pi.h:     section "Present But Cannot Be Compiled"
 configure: WARNING: pi.h: proceeding with the compiler's result
-configure: WARNING:     ## -------------------------------------- ##
+configure: WARNING:     ## --------------------------------------- ##
 configure: WARNING:     ## Report this to bug-example@@example.org ##
-configure: WARNING:     ## -------------------------------------- ##
-checking for pi.h... yes
+configure: WARNING:     ## --------------------------------------- ##
+checking for pi.h... no
 @end smallexample
 
 @noindent
@@ -25988,16 +25963,16 @@ AC_CHECK_HEADERS([number.h pi.h], [], [],
 #endif
 ]])
 $ @kbd{autoconf -Wall}
-$ @kbd{./configure}
+$ @kbd{./configure CPPFLAGS='-I.'}
 checking for gcc... gcc
-checking for C compiler default output... a.out
 checking whether the C compiler works... yes
-checking whether we are cross compiling... no
+checking for C compiler default output file name... a.out
 checking for suffix of executables...
+checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
-checking for gcc option to accept ANSI C... none needed
+checking for gcc option to accept ISO C11... -std=gnu11
 checking for number.h... yes
 checking for pi.h... yes
 @end example
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 614d9b7..808c104 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1437,43 +1437,26 @@ dnl with extended modes being tried first.
 ])# _AC_PROG_CC_C11
 
 
-# _AC_PROG_CC_FORCE_VERSION(LOWER-VERSION, UPPER-VERSION)
-# -------------------------------------------------------
-# Require a compiler for a particular version of C, either C89 or C99.
-# LOWER-VERSION uses lower-case c, UPPER-VERSION uses upper-case.
-AC_DEFUN([_AC_PROG_CC_FORCE_VERSION],
-[ AC_REQUIRE([AC_PROG_CC])dnl
-  if test $ac_prog_cc_stdc != $1; then
-    ac_save_std_CC=$CC
-    if test -n "$ac_prog_cc_stdc_options"; then
-      CC=`expr "X$CC" : 'X\(.*\)'"$ac_prog_cc_stdc_options"
-       ``expr "X$CC" : ".*$ac_prog_cc_stdc_options"'\(.*\)'
-       `
-    fi
-    _AC_PROG_CC_$2(
-       [ac_prog_cc_stdc=$1
-        ac_cv_prog_cc_stdc=$ac_cv_prog_cc_$1],
-       [CC=$ac_save_std_CC
-        AC_MSG_WARN([$2 compiler not available; falling back on $CC])])
-  fi
-])
-
 # AC_PROG_CC_C89
 # --------------
-AC_DEFUN([AC_PROG_CC_C89], [_AC_PROG_CC_FORCE_VERSION([c89], [C89])])
+AC_DEFUN([AC_PROG_CC_C89],
+[ AC_REQUIRE([AC_PROG_CC])dnl
+  m4_warn([obsolete], [$0 is obsolete; use AC_PROG_CC])
+])
 
 # AC_PROG_CC_C99
 # --------------
-AC_DEFUN([AC_PROG_CC_C99], [_AC_PROG_CC_FORCE_VERSION([c99], [C99])])
-
-# There is no AC_PROG_CC_C11, as we have not identified a need for it.
-# Applications should use AC_PROG_CC instead.
-
+AC_DEFUN([AC_PROG_CC_C99],
+[ AC_REQUIRE([AC_PROG_CC])dnl
+  m4_warn([obsolete], [$0 is obsolete; use AC_PROG_CC])
+])
 
 # AC_PROG_CC_STDC
 # ---------------
-# This has been folded into AC_PROG_CC.
-AU_ALIAS([AC_PROG_CC_STDC], [AC_PROG_CC])
+AC_DEFUN([AC_PROG_CC_STDC],
+[ AC_REQUIRE([AC_PROG_CC])dnl
+  m4_warn([obsolete], [$0 is obsolete; use AC_PROG_CC])
+])
 
 
 # AC_C_BACKSLASH_A
-- 
1.7.11.4