diff --git a/ChangeLog b/ChangeLog
index 2ad87825..0f2a6908 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,9 +1,18 @@
+2007-05-14  Paul Eggert  <eggert@cs.ucla.edu>
+
+	* NEWS: Document that AC_C_RESTRICT checks 'restrict' last.
+	* doc/autoconf.texi (C Compiler): Likewise.
+
+2007-05-14  Noah Misch  <noah@cs.caltech.edu>
+
+	* lib/autoconf/c.m4 (AC_C_RESTRICT): Check `restrict' last.
+
 2007-05-09  Stepan Kasal  <kasal@ucw.cz>
 
 	* doc/autoconf.texi: Direntry for "autoconf Invocation"
 	renamed to "autoconf-invocation"
 
-	* doc/autoconf.texi (Caching Results): The CACHE-ID variable 
+	* doc/autoconf.texi (Caching Results): The CACHE-ID variable
 	in the examples should not use the internal "ac_" prefix.
 
 2007-05-05  Noah Misch  <noah@cs.caltech.edu>
diff --git a/NEWS b/NEWS
index a07ee210..ca4615b0 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,10 @@
 
 ** AC_C_BIGENDIAN now supports universal binaries a la Mac OS X.
 
+** AC_C_RESTRICT now prefers to #define 'restrict' to a variant spelling
+   like '__restrict' if the variant spelling is available, as this is
+   more likely to work when mixing C and C++ code.
+
 ** AC_CHECK_ALIGNOF's type argument T is now documented better: it must
    be a string of tokens such that "T y;" is a valid member declaration
    in a struct.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 9abfb940..dd0701df 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -6544,10 +6544,12 @@ New programs need not use this macro.
 @defmac AC_C_RESTRICT
 @acindex{C_RESTRICT}
 @cvindex restrict
-If the C compiler recognizes the @code{restrict} keyword, don't do anything.
-If it recognizes only a variant spelling (@code{__restrict},
-@code{__restrict__}, or @code{_Restrict}), then define
-@code{restrict} to that.
+If the C compiler recognizes a variant spelling for the @code{restrict}
+keyword (@code{__restrict}, @code{__restrict__}, or @code{_Restrict}),
+then define @code{restrict} to that; this is more likely to do the right
+thing with compilers that support language variants where plain
+@code{restrict} is not a keyword.  Otherwise, if the C compiler
+recognizes the @code{restrict} keyword, don't do anything.
 Otherwise, define @code{restrict} to be empty.
 Thus, programs may simply use @code{restrict} as if every C compiler
 supported it; for those that do not, the makefile
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 21d64a1a..7d816b5d 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1647,9 +1647,10 @@ fi
 # http://autoconf-archive.cryp.to/acx_restrict.html
 #
 # Determine whether the C/C++ compiler supports the "restrict" keyword
-# introduced in ANSI C99, or an equivalent.  Do nothing if the compiler
-# accepts it.  Otherwise, if the compiler supports an equivalent,
-# define "restrict" to be that.  Here are some variants:
+# introduced in ANSI C99, or an equivalent.  Define "restrict" to the alternate
+# spelling, if any; these are more likely to work in both C and C++ compilers of
+# the same family, and in the presence of varying compiler options.  If only
+# plain "restrict" works, do nothing.  Here are some variants:
 # - GCC supports both __restrict and __restrict__
 # - older DEC Alpha C compilers support only __restrict
 # - _Restrict is the only spelling accepted by Sun WorkShop 6 update 2 C
@@ -1660,7 +1661,7 @@ AC_DEFUN([AC_C_RESTRICT],
   [ac_cv_c_restrict=no
    # Try the official restrict keyword, then gcc's __restrict, and
    # the less common variants.
-   for ac_kw in restrict __restrict __restrict__ _Restrict; do
+   for ac_kw in __restrict __restrict__ _Restrict restrict; do
      AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
       [[typedef int * int_ptr;
         int foo (int_ptr $ac_kw ip) {