Patchwork PR 45084: Fix misquoting in stdint.m4.

login
register
mail settings
Submitter Ralf Wildenhues
Date Aug. 16, 2010, 8:53 p.m.
Message ID <20100816205339.GE8188@gmx.de>
Download mbox | patch
Permalink /patch/61840/
State New
Headers show

Comments

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.
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

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