c-common.c requires C99

c-common.c requires C99

[Andrew Haley]

C_COMMON_FIXED_TYPES uses empty macro arguments, which aren't defined in C89.

I can't see any way to fix this that's better than defining a pair of macros.
Does anyone have any better ideas?

Andrew.



2008-06-11  Andrew Haley  <aph@littlepinkcloud.com>

	* c-common.c (C_COMMON_FIXED_TYPES_SAT): New macro.
	(C_COMMON_FIXED_TYPES_SAT): New macro.
	(C_COMMON_FIXED_TYPES): Remove first arg.
	(C_COMMON_FIXED_MODE_TYPES): Likewise.

Index: c-common.c
===================================================================
--- c-common.c	(revision 136670)
+++ c-common.c	(working copy)
@@ -2266,53 +2266,77 @@
   if (type1 == intQI_type_node || type1 == unsigned_intQI_type_node)
     return unsignedp ? unsigned_intQI_type_node : intQI_type_node;

-#define C_COMMON_FIXED_TYPES(SAT,NAME) \
-  if (type1 == SAT ## short_ ## NAME ## _type_node \
-      || type1 == SAT ## unsigned_short_ ## NAME ## _type_node) \
-    return unsignedp ? SAT ## unsigned_short_ ## NAME ## _type_node \
-		     : SAT ## short_ ## NAME ## _type_node; \
-  if (type1 == SAT ## NAME ## _type_node \
-      || type1 == SAT ## unsigned_ ## NAME ## _type_node) \
-    return unsignedp ? SAT ## unsigned_ ## NAME ## _type_node \
-		     : SAT ## NAME ## _type_node; \
-  if (type1 == SAT ## long_ ## NAME ## _type_node \
-      || type1 == SAT ## unsigned_long_ ## NAME ## _type_node) \
-    return unsignedp ? SAT ## unsigned_long_ ## NAME ## _type_node \
-		     : SAT ## long_ ## NAME ## _type_node; \
-  if (type1 == SAT ## long_long_ ## NAME ## _type_node \
-      || type1 == SAT ## unsigned_long_long_ ## NAME ## _type_node) \
-    return unsignedp ? SAT ## unsigned_long_long_ ## NAME ## _type_node \
-		     : SAT ## long_long_ ## NAME ## _type_node;
-
-#define C_COMMON_FIXED_MODE_TYPES(SAT,NAME) \
-  if (type1 == SAT ## NAME ## _type_node \
-      || type1 == SAT ## u ## NAME ## _type_node) \
-    return unsignedp ? SAT ## u ## NAME ## _type_node \
-		     : SAT ## NAME ## _type_node;
-
-  C_COMMON_FIXED_TYPES (, fract);
-  C_COMMON_FIXED_TYPES (sat_, fract);
-  C_COMMON_FIXED_TYPES (, accum);
-  C_COMMON_FIXED_TYPES (sat_, accum);
-
-  C_COMMON_FIXED_MODE_TYPES (, qq);
-  C_COMMON_FIXED_MODE_TYPES (, hq);
-  C_COMMON_FIXED_MODE_TYPES (, sq);
-  C_COMMON_FIXED_MODE_TYPES (, dq);
-  C_COMMON_FIXED_MODE_TYPES (, tq);
-  C_COMMON_FIXED_MODE_TYPES (sat_, qq);
-  C_COMMON_FIXED_MODE_TYPES (sat_, hq);
-  C_COMMON_FIXED_MODE_TYPES (sat_, sq);
-  C_COMMON_FIXED_MODE_TYPES (sat_, dq);
-  C_COMMON_FIXED_MODE_TYPES (sat_, tq);
-  C_COMMON_FIXED_MODE_TYPES (, ha);
-  C_COMMON_FIXED_MODE_TYPES (, sa);
-  C_COMMON_FIXED_MODE_TYPES (, da);
-  C_COMMON_FIXED_MODE_TYPES (, ta);
-  C_COMMON_FIXED_MODE_TYPES (sat_, ha);
-  C_COMMON_FIXED_MODE_TYPES (sat_, sa);
-  C_COMMON_FIXED_MODE_TYPES (sat_, da);
-  C_COMMON_FIXED_MODE_TYPES (sat_, ta);
+#define C_COMMON_FIXED_TYPES(NAME)	    \
+  if (type1 == short_ ## NAME ## _type_node \
+      || type1 == unsigned_short_ ## NAME ## _type_node) \
+    return unsignedp ? unsigned_short_ ## NAME ## _type_node \
+		     : short_ ## NAME ## _type_node; \
+  if (type1 == NAME ## _type_node \
+      || type1 == unsigned_ ## NAME ## _type_node) \
+    return unsignedp ? unsigned_ ## NAME ## _type_node \
+		     : NAME ## _type_node; \
+  if (type1 == long_ ## NAME ## _type_node \
+      || type1 == unsigned_long_ ## NAME ## _type_node) \
+    return unsignedp ? unsigned_long_ ## NAME ## _type_node \
+		     : long_ ## NAME ## _type_node; \
+  if (type1 == long_long_ ## NAME ## _type_node \
+      || type1 == unsigned_long_long_ ## NAME ## _type_node) \
+    return unsignedp ? unsigned_long_long_ ## NAME ## _type_node \
+		     : long_long_ ## NAME ## _type_node;
+
+#define C_COMMON_FIXED_MODE_TYPES(NAME) \
+  if (type1 == NAME ## _type_node \
+      || type1 == u ## NAME ## _type_node) \
+    return unsignedp ? u ## NAME ## _type_node \
+		     : NAME ## _type_node;
+
+#define C_COMMON_FIXED_TYPES_SAT(NAME) \
+  if (type1 == sat_ ## short_ ## NAME ## _type_node \
+      || type1 == sat_ ## unsigned_short_ ## NAME ## _type_node) \
+    return unsignedp ? sat_ ## unsigned_short_ ## NAME ## _type_node \
+		     : sat_ ## short_ ## NAME ## _type_node; \
+  if (type1 == sat_ ## NAME ## _type_node \
+      || type1 == sat_ ## unsigned_ ## NAME ## _type_node) \
+    return unsignedp ? sat_ ## unsigned_ ## NAME ## _type_node \
+		     : sat_ ## NAME ## _type_node; \
+  if (type1 == sat_ ## long_ ## NAME ## _type_node \
+      || type1 == sat_ ## unsigned_long_ ## NAME ## _type_node) \
+    return unsignedp ? sat_ ## unsigned_long_ ## NAME ## _type_node \
+		     : sat_ ## long_ ## NAME ## _type_node; \
+  if (type1 == sat_ ## long_long_ ## NAME ## _type_node \
+      || type1 == sat_ ## unsigned_long_long_ ## NAME ## _type_node) \
+    return unsignedp ? sat_ ## unsigned_long_long_ ## NAME ## _type_node \
+		     : sat_ ## long_long_ ## NAME ## _type_node;
+
+#define C_COMMON_FIXED_MODE_TYPES_SAT(NAME)	\
+  if (type1 == sat_ ## NAME ## _type_node \
+      || type1 == sat_ ## u ## NAME ## _type_node) \
+    return unsignedp ? sat_ ## u ## NAME ## _type_node \
+		     : sat_ ## NAME ## _type_node;
+
+  C_COMMON_FIXED_TYPES (fract);
+  C_COMMON_FIXED_TYPES_SAT (fract);
+  C_COMMON_FIXED_TYPES (accum);
+  C_COMMON_FIXED_TYPES_SAT (accum);
+
+  C_COMMON_FIXED_MODE_TYPES (qq);
+  C_COMMON_FIXED_MODE_TYPES (hq);
+  C_COMMON_FIXED_MODE_TYPES (sq);
+  C_COMMON_FIXED_MODE_TYPES (dq);
+  C_COMMON_FIXED_MODE_TYPES (tq);
+  C_COMMON_FIXED_MODE_TYPES_SAT (qq);
+  C_COMMON_FIXED_MODE_TYPES_SAT (hq);
+  C_COMMON_FIXED_MODE_TYPES_SAT (sq);
+  C_COMMON_FIXED_MODE_TYPES_SAT (dq);
+  C_COMMON_FIXED_MODE_TYPES_SAT (tq);
+  C_COMMON_FIXED_MODE_TYPES (ha);
+  C_COMMON_FIXED_MODE_TYPES (sa);
+  C_COMMON_FIXED_MODE_TYPES (da);
+  C_COMMON_FIXED_MODE_TYPES (ta);
+  C_COMMON_FIXED_MODE_TYPES_SAT (ha);
+  C_COMMON_FIXED_MODE_TYPES_SAT (sa);
+  C_COMMON_FIXED_MODE_TYPES_SAT (da);
+  C_COMMON_FIXED_MODE_TYPES_SAT (ta);

   /* For ENUMERAL_TYPEs in C++, must check the mode of the types, not
      the precision; they have precision set to match their range, but

Re: c-common.c requires C99

[Kaveh R. GHAZI]

On Wed, 11 Jun 2008, Andrew Haley wrote:

> C_COMMON_FIXED_TYPES uses empty macro arguments, which aren't defined in C89.
>
> I can't see any way to fix this that's better than defining a pair of macros.
> Does anyone have any better ideas?
>
> Andrew.
>
>
>
> 2008-06-11  Andrew Haley  <aph@littlepinkcloud.com>
>
> 	* c-common.c (C_COMMON_FIXED_TYPES_SAT): New macro.
> 	(C_COMMON_FIXED_TYPES_SAT): New macro.
> 	(C_COMMON_FIXED_TYPES): Remove first arg.
> 	(C_COMMON_FIXED_MODE_TYPES): Likewise.

I suspect this might partially fix PR bootstrap/33304.  If so, I would
like to see it on the 4.3.x branch also.  Oh and you listed
C_COMMON_FIXED_TYPES_SAT twice in the ChangeLog.

My hope is that we could warn about empty macro arguments in C90 mode.
Would you like to pursue this as an enhancement?  PR preprocessor/33305.
:-)
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: c-common.c requires C99

[Andrew Haley]

Kaveh R. GHAZI wrote:
> On Wed, 11 Jun 2008, Andrew Haley wrote:
> 
>> C_COMMON_FIXED_TYPES uses empty macro arguments, which aren't defined in C89.
>>
>> I can't see any way to fix this that's better than defining a pair of macros.
>> Does anyone have any better ideas?
>>
>> Andrew.
>>
>>
>>
>> 2008-06-11  Andrew Haley  <aph@littlepinkcloud.com>
>>
>> 	* c-common.c (C_COMMON_FIXED_TYPES_SAT): New macro.
>> 	(C_COMMON_FIXED_TYPES_SAT): New macro.
>> 	(C_COMMON_FIXED_TYPES): Remove first arg.
>> 	(C_COMMON_FIXED_MODE_TYPES): Likewise.
> 
> I suspect this might partially fix PR bootstrap/33304.  If so, I would
> like to see it on the 4.3.x branch also.  Oh and you listed
> C_COMMON_FIXED_TYPES_SAT twice in the ChangeLog.
> 
> My hope is that we could warn about empty macro arguments in C90 mode.
> Would you like to pursue this as an enhancement?  PR preprocessor/33305.
> :-)

OK.

Andrew.

PR preprocessor/33305: Warn for empty macro arguments

[Andrew Haley]

Andrew Haley wrote:
> Kaveh R. GHAZI wrote:
>> On Wed, 11 Jun 2008, Andrew Haley wrote:
>>
>>> C_COMMON_FIXED_TYPES uses empty macro arguments, which aren't defined in C89.
>>>
>>> I can't see any way to fix this that's better than defining a pair of macros.
>>> Does anyone have any better ideas?
>>>
>>> Andrew.
>>>
>>>
>>>
>>> 2008-06-11  Andrew Haley  <aph@littlepinkcloud.com>
>>>
>>> 	* c-common.c (C_COMMON_FIXED_TYPES_SAT): New macro.
>>> 	(C_COMMON_FIXED_TYPES_SAT): New macro.
>>> 	(C_COMMON_FIXED_TYPES): Remove first arg.
>>> 	(C_COMMON_FIXED_MODE_TYPES): Likewise.
>> I suspect this might partially fix PR bootstrap/33304.  If so, I would
>> like to see it on the 4.3.x branch also.  Oh and you listed
>> C_COMMON_FIXED_TYPES_SAT twice in the ChangeLog.
>>
>> My hope is that we could warn about empty macro arguments in C90 mode.
>> Would you like to pursue this as an enhancement?  PR preprocessor/33305.
>> :-)

The easiest place to detect this is at expansion time.  This prints the
file and line number at the point the macro is expanded and it also names
the macro and the arg, to help with debugging.  This has revealed a few places
in the gcc source where we use empty macro arguments, and I'll follow up with
a patch for those.

Andrew.


2008-06-13  Andrew Haley  <aph@redhat.com>

	PR preprocessor/33305:
	* macro.c (replace_args): Print a warning for empty macro
	arguments in C89.

Index: macro.c
===================================================================
--- macro.c	(revision 135765)
+++ macro.c	(working copy)
@@ -1009,6 +1009,15 @@
 	  if (src->flags & PASTE_LEFT)
 	    paste_flag = dest - 1;
 	}
+      else if (! CPP_OPTION (pfile, c99)
+	       && ! cpp_in_system_header (pfile))
+	{
+	  cpp_error (pfile, CPP_DL_WARNING,
+		     "in macro %s arg %d: "
+		     "empty macro arguments are undefined in C89",
+		     NODE_NAME (node),
+		     src->val.arg_no);
+	}

       /* Avoid paste on RHS (even case count == 0).  */
       if (!pfile->state.in_directive && !(src->flags & PASTE_LEFT))

Re: PR preprocessor/33305: Warn for empty macro arguments

[Joseph S. Myers]

On Fri, 13 Jun 2008, Andrew Haley wrote:

> +		     "in macro %s arg %d: "
> +		     "empty macro arguments are undefined in C89",

Such diagnostics in GCC conventionally say "ISO C90".  If compiling C++, 
it should say "ISO C++" instead.  (I have not checked whether the C++0x 
draft allows empty macro arguments; if so, "ISO C++98" would be the right 
thing to say for C++.)

-- 
Joseph S. Myers
joseph@codesourcery.com

tree.c requires C99

[Andrew Haley]

... same again.  Remove use of empty macro arguments.

Andrew.


	* tree.c (MAKE_FIXED_TYPE_NODE): Break into two macros,
	MAKE_FIXED_TYPE_NODE and MAKE_FIXED_TYPE_NODE_WIDTH in order
	not to use empty macro arguments.

Index: tree.c
===================================================================
--- tree.c	(revision 136670)
+++ tree.c	(working copy)
@@ -7296,7 +7296,16 @@
   complex_long_double_type_node = build_complex_type (long_double_type_node);

 /* Make fixed-point nodes based on sat/non-sat and signed/unsigned.  */
-#define MAKE_FIXED_TYPE_NODE(KIND,WIDTH,SIZE) \
+#define MAKE_FIXED_TYPE_NODE(KIND,SIZE) \
+  sat_ ## KIND ## _type_node = \
+    make_sat_signed_ ## KIND ## _type (SIZE); \
+  sat_unsigned_ ## KIND ## _type_node = \
+    make_sat_unsigned_ ## KIND ## _type (SIZE); \
+  KIND ## _type_node = make_signed_ ## KIND ## _type (SIZE); \
+  unsigned_ ## KIND ## _type_node = \
+    make_unsigned_ ## KIND ## _type (SIZE);
+
+#define MAKE_FIXED_TYPE_NODE_WIDTH(KIND,WIDTH,SIZE) \
   sat_ ## WIDTH ## KIND ## _type_node = \
     make_sat_signed_ ## KIND ## _type (SIZE); \
   sat_unsigned_ ## WIDTH ## KIND ## _type_node = \
@@ -7307,10 +7316,10 @@

 /* Make fixed-point type nodes based on four different widths.  */
 #define MAKE_FIXED_TYPE_NODE_FAMILY(N1,N2) \
-  MAKE_FIXED_TYPE_NODE (N1, short_, SHORT_ ## N2 ## _TYPE_SIZE) \
-  MAKE_FIXED_TYPE_NODE (N1, , N2 ## _TYPE_SIZE) \
-  MAKE_FIXED_TYPE_NODE (N1, long_, LONG_ ## N2 ## _TYPE_SIZE) \
-  MAKE_FIXED_TYPE_NODE (N1, long_long_, LONG_LONG_ ## N2 ## _TYPE_SIZE)
+  MAKE_FIXED_TYPE_NODE_WIDTH (N1, short_, SHORT_ ## N2 ## _TYPE_SIZE) \
+  MAKE_FIXED_TYPE_NODE (N1, N2 ## _TYPE_SIZE) \
+  MAKE_FIXED_TYPE_NODE_WIDTH (N1, long_, LONG_ ## N2 ## _TYPE_SIZE) \
+  MAKE_FIXED_TYPE_NODE_WIDTH (N1, long_long_, LONG_LONG_ ## N2 ## _TYPE_SIZE)

 /* Make fixed-point mode nodes based on sat/non-sat and signed/unsigned.  */
 #define MAKE_FIXED_MODE_NODE(KIND,NAME,MODE) \

Re: PR preprocessor/33305: Warn for empty macro arguments

[Joseph S. Myers]

Also, such a diagnostic should be restricted to -pedantic if your patch 
doesn't so restrict it, and needs testcases.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PR preprocessor/33305: Warn for empty macro arguments

[Andrew Haley]

Joseph S. Myers wrote:
> Also, such a diagnostic should be restricted to -pedantic if your patch 
> doesn't so restrict it, and needs testcases.

I can do that.  I don't agree that it should be restricted to -pedantic.
Why do you think it should be?

> and needs testcases.

Certainly.

Andrew.

Re: PR preprocessor/33305: Warn for empty macro arguments

[Andrew Haley]

Andrew Haley wrote:
> Andrew Haley wrote:
>> Kaveh R. GHAZI wrote:
>>> On Wed, 11 Jun 2008, Andrew Haley wrote:
>>>
>>>> C_COMMON_FIXED_TYPES uses empty macro arguments, which aren't defined in C89.
>>>>
>>>> I can't see any way to fix this that's better than defining a pair of macros.
>>>> Does anyone have any better ideas?
>>>>
>>>> Andrew.
>>>>
>>>>
>>>>
>>>> 2008-06-11  Andrew Haley  <aph@littlepinkcloud.com>
>>>>
>>>> 	* c-common.c (C_COMMON_FIXED_TYPES_SAT): New macro.
>>>> 	(C_COMMON_FIXED_TYPES_SAT): New macro.
>>>> 	(C_COMMON_FIXED_TYPES): Remove first arg.
>>>> 	(C_COMMON_FIXED_MODE_TYPES): Likewise.
>>> I suspect this might partially fix PR bootstrap/33304.  If so, I would
>>> like to see it on the 4.3.x branch also.  Oh and you listed
>>> C_COMMON_FIXED_TYPES_SAT twice in the ChangeLog.
>>>
>>> My hope is that we could warn about empty macro arguments in C90 mode.
>>> Would you like to pursue this as an enhancement?  PR preprocessor/33305.
>>> :-)
> 
> The easiest place to detect this is at expansion time. 

I withdraw this patch; I'm working on a better one.

Andrew.

Re: PR preprocessor/33305: Warn for empty macro arguments

[Joseph S. Myers]

On Fri, 13 Jun 2008, Andrew Haley wrote:

> Joseph S. Myers wrote:
> > Also, such a diagnostic should be restricted to -pedantic if your patch 
> > doesn't so restrict it, and needs testcases.
> 
> I can do that.  I don't agree that it should be restricted to -pedantic.
> Why do you think it should be?

It's a warning for the use of a GNU extension (a C99 feature supported as 
an extension in C90 mode), and such warnings are normally conditioned on 
-pedantic; we accept GNU extensions without warning by default.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PR preprocessor/33305: Warn for empty macro arguments

[Kaveh R. Ghazi]

From: "Andrew Haley" <aph@redhat.com>

> Joseph S. Myers wrote:
>> Also, such a diagnostic should be restricted to -pedantic if your patch
>> doesn't so restrict it, and needs testcases.
>
> I can do that.  I don't agree that it should be restricted to -pedantic.
> Why do you think it should be?

Because users who don't care about ISO C90 compatibility will consider this 
warning to be noise.  I would recommend doing something like the -Wlong-long 
flag, where -pedantic activates it by default but -Wno-long-long can 
selectively turn it off.  GCC already uses -pedantic, so no additional 
bootstrap flags would be necessary.

Maybe call it -Wempty-macro-args ?

        --Kaveh

Re: PR preprocessor/33305: Warn for empty macro arguments

[Andrew Haley]

Joseph S. Myers wrote:
> On Fri, 13 Jun 2008, Andrew Haley wrote:
> 
>> Joseph S. Myers wrote:
>>> Also, such a diagnostic should be restricted to -pedantic if your patch 
>>> doesn't so restrict it, and needs testcases.
>> I can do that.  I don't agree that it should be restricted to -pedantic.
>> Why do you think it should be?
> 
> It's a warning for the use of a GNU extension (a C99 feature supported as 
> an extension in C90 mode), and such warnings are normally conditioned on 
> -pedantic; we accept GNU extensions without warning by default.

OK, I see.

Thanks,
Andrew.

Re: PR preprocessor/33305: Warn for empty macro arguments

[Andrew Haley]

Kaveh R. Ghazi wrote:
> From: "Andrew Haley" <aph@redhat.com>
> 
>> Joseph S. Myers wrote:
>>> Also, such a diagnostic should be restricted to -pedantic if your patch
>>> doesn't so restrict it, and needs testcases.
>>
>> I can do that.  I don't agree that it should be restricted to -pedantic.
>> Why do you think it should be?
> 
> Because users who don't care about ISO C90 compatibility will consider
> this warning to be noise.  I would recommend doing something like the
> -Wlong-long flag, where -pedantic activates it by default but
> -Wno-long-long can selectively turn it off.  GCC already uses -pedantic,
> so no additional bootstrap flags would be necessary.
> 
> Maybe call it -Wempty-macro-args ?

Look what you've got me into now.  :-)

Andrew.

Re: PR preprocessor/33305: Warn for empty macro arguments

[Manuel López-Ibáñez]

2008/6/13 Andrew Haley <aph@redhat.com>:
> Kaveh R. Ghazi wrote:
>> From: "Andrew Haley" <aph@redhat.com>
>>
>>> Joseph S. Myers wrote:
>>>> Also, such a diagnostic should be restricted to -pedantic if your patch
>>>> doesn't so restrict it, and needs testcases.
>>>
>>> I can do that.  I don't agree that it should be restricted to -pedantic.
>>> Why do you think it should be?
>>
>> Because users who don't care about ISO C90 compatibility will consider
>> this warning to be noise.  I would recommend doing something like the
>> -Wlong-long flag, where -pedantic activates it by default but
>> -Wno-long-long can selectively turn it off.  GCC already uses -pedantic,
>> so no additional bootstrap flags would be necessary.
>>
>> Maybe call it -Wempty-macro-args ?
>
> Look what you've got me into now.  :-)

Do you know for sure that users of -pedantic would like to turn this
off? Typically you use pedantic to warn about GNU extensions that may
not be supported in other compilers. I think we don't need a separate
flag if users don't care about turning this off. We don't want one
flag for every -pedantic warning, do we? If users complain, we can
easily add such a flag later.

Cheers,

Manuel.

Re: PR preprocessor/33305: Warn for empty macro arguments

[Kaveh R. Ghazi]

From: "Manuel López-Ibáñez" <lopezibanez@gmail.com>

>>> Because users who don't care about ISO C90 compatibility will consider
>>> this warning to be noise.  I would recommend doing something like the
>>> -Wlong-long flag, where -pedantic activates it by default but
>>> -Wno-long-long can selectively turn it off.  GCC already uses -pedantic,
>>> so no additional bootstrap flags would be necessary.
>>>
>>> Maybe call it -Wempty-macro-args ?
>>
>> Look what you've got me into now.  :-)
>
> Do you know for sure that users of -pedantic would like to turn this
> off? Typically you use pedantic to warn about GNU extensions that may
> not be supported in other compilers. I think we don't need a separate
> flag if users don't care about turning this off. We don't want one
> flag for every -pedantic warning, do we? If users complain, we can
> easily add such a flag later.

That's fine with me.  Andrew, if it's too much trouble feel free to ignore 
my suggestion.

--Kaveh

Re: PR preprocessor/33305: Warn for empty macro arguments

[Andrew Haley]

Kaveh R. Ghazi wrote:
> From: "Manuel López-Ibáñez" <lopezibanez@gmail.com>
> 
>>>> Because users who don't care about ISO C90 compatibility will consider
>>>> this warning to be noise.  I would recommend doing something like the
>>>> -Wlong-long flag, where -pedantic activates it by default but
>>>> -Wno-long-long can selectively turn it off.  GCC already uses
>>>> -pedantic,
>>>> so no additional bootstrap flags would be necessary.
>>>>
>>>> Maybe call it -Wempty-macro-args ?
>>>
>>> Look what you've got me into now.  :-)
>>
>> Do you know for sure that users of -pedantic would like to turn this
>> off? Typically you use pedantic to warn about GNU extensions that may
>> not be supported in other compilers. I think we don't need a separate
>> flag if users don't care about turning this off. We don't want one
>> flag for every -pedantic warning, do we? If users complain, we can
>> easily add such a flag later.
> 
> That's fine with me.  Andrew, if it's too much trouble feel free to
> ignore my suggestion.

OK.  As a matter of general policy I'm against adding flags to gcc
unless they are certainly needed.

Andrew.

Please help with 33304: global write privs / C maintainers

[Andrew Haley]

This is pr bootstrap/33304

There a several patches needed to fix this.

These two are in c-common.c and c-tree.c:

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00687.html
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00858.html

The cpp front end change <http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01185.html>
is already approved, as are the cpp test cases.
However, this change to the c++ test suite is not yet approved:

(See http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01346.html for context)

Index: g++.dg/ext/gnu-inline-global-reject.C
===================================================================
--- g++.dg/ext/gnu-inline-global-reject.C	(revision 136895)
+++ g++.dg/ext/gnu-inline-global-reject.C	(working copy)
@@ -4,6 +4,7 @@
 */

 /* { dg-do compile } */
+/* { dg-options " -ansi -Wno-long-long" } */

 #include "gnu-inline-common.h"

Until this change to the c++ test suite and the c-common.c and c-tree.c
fixes are approved, my (already approved) cpp fix can't go in.

Andrew.

Re: Please help with 33304: global write privs / C maintainers

[Janis Johnson]

On Mon, 2008-06-30 at 16:36 +0100, Andrew Haley wrote:
> This is pr bootstrap/33304
> 
> There a several patches needed to fix this.
> 
> These two are in c-common.c and c-tree.c:
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00687.html
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00858.html
> 
> The cpp front end change <http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01185.html>
> is already approved, as are the cpp test cases.
> However, this change to the c++ test suite is not yet approved:
> 
> (See http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01346.html for context)
> 
> Index: g++.dg/ext/gnu-inline-global-reject.C
> ===================================================================
> --- g++.dg/ext/gnu-inline-global-reject.C	(revision 136895)
> +++ g++.dg/ext/gnu-inline-global-reject.C	(working copy)
> @@ -4,6 +4,7 @@
>  */
> 
>  /* { dg-do compile } */
> +/* { dg-options " -ansi -Wno-long-long" } */
> 
>  #include "gnu-inline-common.h"
> 
> Until this change to the c++ test suite and the c-common.c and c-tree.c
> fixes are approved, my (already approved) cpp fix can't go in.

Adding -ansi is fine, but what's the purpose of -Wno-long-long?

Janis

Re: Please help with 33304: global write privs / C maintainers

[Michael Meissner]

On Mon, Jun 30, 2008 at 04:36:23PM +0100, Andrew Haley wrote:
> This is pr bootstrap/33304
> 
> There a several patches needed to fix this.
> 
> These two are in c-common.c and c-tree.c:
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00687.html
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00858.html
> 
> The cpp front end change <http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01185.html>
> is already approved, as are the cpp test cases.
> However, this change to the c++ test suite is not yet approved:

I just re-read 6.8.3.3 of the ISO C 89/90 standard, and it is undefined.

While there might be ways of writing just one macro (for example, passing an
argument of '_') it isn't that big of a deal IMHO, and I approve of the
changes.

> (See http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01346.html for context)
> 
> Index: g++.dg/ext/gnu-inline-global-reject.C
> ===================================================================
> --- g++.dg/ext/gnu-inline-global-reject.C	(revision 136895)
> +++ g++.dg/ext/gnu-inline-global-reject.C	(working copy)
> @@ -4,6 +4,7 @@
>  */
> 
>  /* { dg-do compile } */
> +/* { dg-options " -ansi -Wno-long-long" } */
> 
>  #include "gnu-inline-common.h"
> 
> Until this change to the c++ test suite and the c-common.c and c-tree.c
> fixes are approved, my (already approved) cpp fix can't go in.

This looks reasonable.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org

Re: Please help with 33304: global write privs / C maintainers

[Andrew Haley]

Janis Johnson wrote:
> On Mon, 2008-06-30 at 16:36 +0100, Andrew Haley wrote:
>> This is pr bootstrap/33304
>>
>> There a several patches needed to fix this.
>>
>> These two are in c-common.c and c-tree.c:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00687.html
>> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00858.html
>>
>> The cpp front end change <http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01185.html>
>> is already approved, as are the cpp test cases.
>> However, this change to the c++ test suite is not yet approved:
>>
>> (See http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01346.html for context)
>>
>> Index: g++.dg/ext/gnu-inline-global-reject.C
>> ===================================================================
>> --- g++.dg/ext/gnu-inline-global-reject.C	(revision 136895)
>> +++ g++.dg/ext/gnu-inline-global-reject.C	(working copy)
>> @@ -4,6 +4,7 @@
>>  */
>>
>>  /* { dg-do compile } */
>> +/* { dg-options " -ansi -Wno-long-long" } */
>>
>>  #include "gnu-inline-common.h"
>>
>> Until this change to the c++ test suite and the c-common.c and c-tree.c
>> fixes are approved, my (already approved) cpp fix can't go in.
> 
> Adding -ansi is fine, but what's the purpose of -Wno-long-long?

The default flags are " -ansi -pedantic-errors -Wno-long-long"

My patch merely removes -pedantic-errors.

Andrew.