PR 45084: Fix misquoting in stdint.m4.

Submitted by Ralf Wildenhues on Aug. 16, 2010, 8:53 p.m.

Details

Message ID 20100816205339.GE8188@gmx.de
State New
Headers show

Commit Message

Ralf Wildenhues Aug. 16, 2010, 8:53 p.m.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084 shows a fairly weird
GCC build error message.  The weirdness stems from underquoted M4 macro
arguments containing comma.

The patch is obvious (to me, at least).  OK to apply and sync to src
(where bfd/configure needs regenerating for this, too)?

What about backports?  The bug is present in some form in all active
branches.

FYI, the expanded code changes like this:

|  $as_echo_n "checking for type equivalent to int8_t... " >&6; }
|    case "$ac_cv_sizeof_char" in
|      1) acx_cv_type_int8_t=char ;;
| -    *) { as_fn_set_status please report a bug
| -as_fn_error "no 8-bit type" "$LINENO" 5; }
| +    *) as_fn_error "no 8-bit type, please report a bug" "$LINENO" 5
|    esac

Thanks,
Ralf

ChangeLog entries for GCC:

Fix misquoting in stdint.m4.

config/ChangeLog:
2010-08-16  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	PR target/45084
	* stdint.m4 (GCC_HEADER_STDINT): Use m4 quotes for arguments
	of AC_MSG_ERROR.

libdecnumber/ChangeLog:
2010-08-16  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

libgfortran/ChangeLog:
2010-08-16  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

libgomp/ChangeLog:
2010-08-16  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

libstdc++-v3/ChangeLog:
2010-08-16  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

Comments

Paolo Bonzini Aug. 16, 2010, 8:56 p.m.
On Mon, Aug 16, 2010 at 22:53, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084 shows a fairly weird
> GCC build error message.  The weirdness stems from underquoted M4 macro
> arguments containing comma.
>
> The patch is obvious (to me, at least).  OK to apply and sync to src
> (where bfd/configure needs regenerating for this, too)?

Yes.

> What about backports?  The bug is present in some form in all active
> branches.

If you really care... The code is triggering only because the compiler
is totally broken to begin with.

Paolo

Patch hide | download patch | download mbox

diff --git a/config/stdint.m4 b/config/stdint.m4
index d63081d..fbdd586 100644
--- a/config/stdint.m4
+++ b/config/stdint.m4
@@ -146,7 +146,7 @@  if test $acx_cv_header_stdint = stddef.h; then
   AC_MSG_CHECKING(for type equivalent to int8_t)
   case "$ac_cv_sizeof_char" in
     1) acx_cv_type_int8_t=char ;;
-    *) AC_MSG_ERROR(no 8-bit type, please report a bug)
+    *) AC_MSG_ERROR([no 8-bit type, please report a bug])
   esac
   AC_MSG_RESULT($acx_cv_type_int8_t)
 
@@ -154,7 +154,7 @@  if test $acx_cv_header_stdint = stddef.h; then
   case "$ac_cv_sizeof_int:$ac_cv_sizeof_short" in
     2:*) acx_cv_type_int16_t=int ;;
     *:2) acx_cv_type_int16_t=short ;;
-    *) AC_MSG_ERROR(no 16-bit type, please report a bug)
+    *) AC_MSG_ERROR([no 16-bit type, please report a bug])
   esac
   AC_MSG_RESULT($acx_cv_type_int16_t)
 
@@ -162,7 +162,7 @@  if test $acx_cv_header_stdint = stddef.h; then
   case "$ac_cv_sizeof_int:$ac_cv_sizeof_long" in
     4:*) acx_cv_type_int32_t=int ;;
     *:4) acx_cv_type_int32_t=long ;;
-    *) AC_MSG_ERROR(no 32-bit type, please report a bug)
+    *) AC_MSG_ERROR([no 32-bit type, please report a bug])
   esac
   AC_MSG_RESULT($acx_cv_type_int32_t)
 fi
@@ -185,7 +185,7 @@  if test "$ac_cv_type_uintptr_t" != yes; then
     2) acx_cv_type_intptr_t=int16_t ;;
     4) acx_cv_type_intptr_t=int32_t ;;
     8) acx_cv_type_intptr_t=int64_t ;;
-    *) AC_MSG_ERROR(no equivalent for intptr_t, please report a bug)
+    *) AC_MSG_ERROR([no equivalent for intptr_t, please report a bug])
   esac
   AC_MSG_RESULT($acx_cv_type_intptr_t)
 fi