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 <egg...@cs.ucla.edu>
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},
+@code{_Static_assert}, 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,
+@code{inline}, signed and unsigned @code{long long int}, mixed code and
+declarations, named initialization of structs, @code{restrict},
+@code{va_copy}, 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}).
-@defmac AC_PROG_CC_C89
-@acindex{PROG_CC_C89}
-@caindex 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
-@code{ac_cv_prog_cc_c89} 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.
-@end defmac
-
-@defmac AC_PROG_CC_C99
-@acindex{PROG_CC_C99}
-@caindex 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},
-@code{//} comments, flexible array members, @code{inline}, signed and
-unsigned @code{long long int}, mixed code and declarations, named
-initialization of structs,
-@code{restrict}, @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
-@code{ac_cv_prog_cc_c99} 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.
-@end 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
-@command{c89} and anyway these standard names are rarely used in
+@command{c89}, future POSIX standards will likely specify
+@command{c11}, 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
-@code{sig_atomic_t 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
+@defmac AC_PROG_CC_C89
+@acindex{PROG_CC_C89}
+Now done by @code{AC_PROG_CC} (@pxref{AC_PROG_CC}).
+@end defmac
+
+@defmac AC_PROG_CC_C99
+@acindex{PROG_CC_C99}
+Now done by @code{AC_PROG_CC} (@pxref{AC_PROG_CC}).
+@end 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
