Candidate fix for PR c/7353

Candidate fix for PR c/7353

[Zack Weinberg]

PR c/7353, distilled, reports that 

typedef A = 0;  /* equivalent to 'typedef int A;' */

produces an ICE with all versions of GCC since 3.0.  This is an
obscure, rarely-used extension, but if we're going to have it, it
should work.

There are two bugs.  One is that make_decl_rtl is being called on a
TYPE_DECL; it quite properly aborts.  The other is that the code for
handling 'typedef T = expr' was not updated when DECL_ORIGINAL_TYPE
was invented, so we abort in gen_typedef_die.

I believe this patch fixes the bug.  I have one remaining concern:
given

typedef A = 0;
A a;

gdb reports

(gdb) ptype a
type = int

Shouldn't that be type = A?  It does do the same thing for

typedef int B;
B b;

so perhaps this is as intended.

zw

	* c-decl.c (finish_decl): When processing 'typedef T = expr',
	TREE_TYPE (T) should be a copy of TREE_TYPE (expr), as is done
	for normal typedefs.
	* toplev.c (rest_of_decl_compilation): Do not call
	make_decl_rtl on TYPE_DECLs.

===================================================================
Index: c-decl.c
--- c-decl.c	22 Sep 2002 02:03:14 -0000	1.350
+++ c-decl.c	7 Oct 2002 23:45:48 -0000
@@ -2994,7 +2994,8 @@ finish_decl (decl, init, asmspec_tree)
       else
 	{
 	  /* typedef foo = bar; store the type of bar as the type of foo.  */
-	  TREE_TYPE (decl) = TREE_TYPE (init);
+	  TREE_TYPE (decl) = build_type_copy (TREE_TYPE (init));
+	  DECL_ORIGINAL_TYPE (decl) = TREE_TYPE (init);
 	  DECL_INITIAL (decl) = init = 0;
 	}
     }
===================================================================
Index: toplev.c
--- toplev.c	7 Oct 2002 03:01:39 -0000	1.679
+++ toplev.c	7 Oct 2002 23:45:52 -0000
@@ -2272,8 +2272,9 @@ rest_of_decl_compilation (decl, asmspec,
 
   /* Forward declarations for nested functions are not "external",
      but we need to treat them as if they were.  */
-  if (TREE_STATIC (decl) || DECL_EXTERNAL (decl)
-      || TREE_CODE (decl) == FUNCTION_DECL)
+  if (TREE_CODE (decl) == FUNCTION_DECL
+      || (TREE_CODE (decl) == VAR_DECL
+	  && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))))
     {
       timevar_push (TV_VARCONST);
 

Re: Candidate fix for PR c/7353

[Richard Henderson]

On Mon, Oct 07, 2002 at 04:52:25PM -0700, Zack Weinberg wrote:
> typedef A = 0;  /* equivalent to 'typedef int A;' */

Huh?  Oh blah.

Clearly the existing "typedef __typeof(0) A;" extension
was too obvious.  I suppose I'm being unfair; it's possible
that this one came first.  Certainly the later is more
generically useful though.

> produces an ICE with all versions of GCC since 3.0.  This is an
> obscure, rarely-used extension, but if we're going to have it, it
> should work.

I'm for nuking it myself.  If there's not unanimous agreement,
I guess I'll look at your patch tomorrow.

> Shouldn't that be type = A?  It does do the same thing for
> 
> typedef int B;
> B b;
> 
> so perhaps this is as intended.

Yes, that's intended.


r~

Re: Candidate fix for PR c/7353

[Neil Booth]

Richard Henderson wrote:-

> > produces an ICE with all versions of GCC since 3.0.  This is an
> > obscure, rarely-used extension, but if we're going to have it, it
> > should work.
> 
> I'm for nuking it myself.

I concur.  It's really ugly.

Neil.

Re: Candidate fix for PR c/7353

[Zack Weinberg]

On Mon, Oct 07, 2002 at 10:59:31PM -0700, Richard Henderson wrote:
> > produces an ICE with all versions of GCC since 3.0.  This is an
> > obscure, rarely-used extension, but if we're going to have it, it
> > should work.
> 
> I'm for nuking it myself.  If there's not unanimous agreement,
> I guess I'll look at your patch tomorrow.

It's a documented extension, so we might want to deprecate it for a
release before making it go away, but since it's been broken since 3.0
and only one person has complained, I certainly wouldn't object to
killing it immediately.

Here's a patch to eliminate it altogether, so all alternatives will be
on the table.  (Note that C++ generates three error messages for the
construct with this patch, which is overkill IMO.)

zw

	* c-decl.c (start_decl): It is always an error to write
	"typedef T = expr;".
	(finish_decl): Remove special case for TYPE_DECL with nonzero INIT.
	* cp/decl.c: Likewise.

	* doc/extend.texi: Delete documentation of "typedef T = expr;"
	extension.  Move useful example there to the "typeof" section,
	and rewrite it to use that extension instead.  Delete silly
	typeof example.  Change cross-references to "Naming Types" to
	refer to "Typeof" instead.

===================================================================
Index: c-decl.c
--- c-decl.c	22 Sep 2002 02:03:14 -0000	1.350
+++ c-decl.c	8 Oct 2002 06:47:21 -0000
@@ -2821,15 +2821,9 @@ start_decl (declarator, declspecs, initi
     switch (TREE_CODE (decl))
       {
       case TYPE_DECL:
-	/* typedef foo = bar  means give foo the same type as bar.
-	   We haven't parsed bar yet, so `finish_decl' will fix that up.
-	   Any other case of an initialization in a TYPE_DECL is an error.  */
-	if (pedantic || list_length (declspecs) > 1)
-	  {
-	    error ("typedef `%s' is initialized",
-		   IDENTIFIER_POINTER (DECL_NAME (decl)));
-	    initialized = 0;
-	  }
+	error ("typedef `%s' is initialized",
+	       IDENTIFIER_POINTER (DECL_NAME (decl)));
+	initialized = 0;
 	break;
 
       case FUNCTION_DECL:
@@ -2988,16 +2982,7 @@ finish_decl (decl, init, asmspec_tree)
     init = 0;
 
   if (init)
-    {
-      if (TREE_CODE (decl) != TYPE_DECL)
-	store_init_value (decl, init);
-      else
-	{
-	  /* typedef foo = bar; store the type of bar as the type of foo.  */
-	  TREE_TYPE (decl) = TREE_TYPE (init);
-	  DECL_INITIAL (decl) = init = 0;
-	}
-    }
+    store_init_value (decl, init);
 
   /* Deduce size of array from initialization, if not already known */
   if (TREE_CODE (type) == ARRAY_TYPE
===================================================================
Index: cp/decl.c
--- cp/decl.c	2 Oct 2002 18:46:40 -0000	1.942
+++ cp/decl.c	8 Oct 2002 06:53:42 -0000
@@ -7290,14 +7290,8 @@ start_decl (declarator, declspecs, initi
     switch (TREE_CODE (decl))
       {
       case TYPE_DECL:
-	/* typedef foo = bar  means give foo the same type as bar.
-	   We haven't parsed bar yet, so `cp_finish_decl' will fix that up.
-	   Any other case of an initialization in a TYPE_DECL is an error.  */
-	if (pedantic || list_length (declspecs) > 1)
-	  {
-	    error ("typedef `%D' is initialized", decl);
-	    initialized = 0;
-	  }
+	error ("typedef `%D' is initialized", decl);
+	initialized = 0;
 	break;
 
       case FUNCTION_DECL:
@@ -8156,12 +8150,6 @@ cp_finish_decl (decl, init, asmspec_tree
   /* Take care of TYPE_DECLs up front.  */
   if (TREE_CODE (decl) == TYPE_DECL)
     {
-      if (init && DECL_INITIAL (decl))
-	{
-	  /* typedef foo = bar; store the type of bar as the type of foo.  */
-	  TREE_TYPE (decl) = type = TREE_TYPE (init);
-	  DECL_INITIAL (decl) = init = NULL_TREE;
-	}
       if (type != error_mark_node
 	  && IS_AGGR_TYPE (type) && DECL_NAME (decl))
 	{
===================================================================
Index: doc/extend.texi
--- doc/extend.texi	27 Sep 2002 13:30:07 -0000	1.104
+++ doc/extend.texi	8 Oct 2002 06:47:23 -0000
@@ -427,7 +427,6 @@ extensions, accepted by GCC in C89 mode 
 * Labels as Values::    Getting pointers to labels, and computed gotos.
 * Nested Functions::    As in Algol and Pascal, lexical scoping of functions.
 * Constructing Calls::	Dispatching a call to another function.
-* Naming Types::        Giving a name to the type of some expression.
 * Typeof::              @code{typeof}: referring to the type of an expression.
 * Lvalues::             Using @samp{?:}, @samp{,} and casts in lvalues.
 * Conditionals::        Omitting the middle operand of a @samp{?:} expression.
@@ -538,8 +537,7 @@ the value of an enumeration constant, th
 the initial value of a static variable.
 
 If you don't know the type of the operand, you can still do this, but you
-must use @code{typeof} (@pxref{Typeof}) or type naming (@pxref{Naming
-Types}).
+must use @code{typeof} (@pxref{Typeof}).
 
 Statement expressions are not supported fully in G++, and their fate
 there is unclear.  (It is possible that they will become fully supported
@@ -888,29 +886,6 @@ the containing function.  You should spe
 returned by @code{__builtin_apply}.
 @end deftypefn
 
-@node Naming Types
-@section Naming an Expression's Type
-@cindex naming types
-
-You can give a name to the type of an expression using a @code{typedef}
-declaration with an initializer.  Here is how to define @var{name} as a
-type name for the type of @var{exp}:
-
-@example
-typedef @var{name} = @var{exp};
-@end example
-
-This is useful in conjunction with the statements-within-expressions
-feature.  Here is how the two together can be used to define a safe
-``maximum'' macro that operates on any arithmetic type:
-
-@example
-#define max(a,b) \
-  (@{typedef _ta = (a), _tb = (b);  \
-    _ta _a = (a); _tb _b = (b);     \
-    _a > _b ? _a : _b; @})
-@end example
-
 @cindex underscores in variables in macros
 @cindex @samp{_} in variables in macros
 @cindex local variables in macros
@@ -962,6 +937,20 @@ A @code{typeof}-construct can be used an
 used.  For example, you can use it in a declaration, in a cast, or inside
 of @code{sizeof} or @code{typeof}.
 
+@code{typeof} is often useful in conjunction with the
+statements-within-expressions feature.  Here is how the two together can
+be used to define a safe ``maximum'' macro that operates on any
+arithmetic type and evaluates each of its arguments exactly once:
+
+@example
+#define max(a,b) \
+  (@{ typeof (a) _a = (a); \
+      typeof (b) _b = (b); \
+    _a > _b ? _a : _b; @})
+@end example
+
+Some more examples of the use of @code{typeof}:
+
 @itemize @bullet
 @item
 This declares @code{y} with the type of what @code{x} points to.
@@ -976,39 +965,6 @@ This declares @code{y} as an array of su
 @example
 typeof (*x) y[4];
 @end example
-
-@item
-This declares @code{y} as an array of pointers to characters:
-
-@example
-typeof (typeof (char *)[4]) y;
-@end example
-
-@noindent
-It is equivalent to the following traditional C declaration:
-
-@example
-char *y[4];
-@end example
-
-To see the meaning of the declaration using @code{typeof}, and why it
-might be a useful way to write, let's rewrite it with these macros:
-
-@example
-#define pointer(T)  typeof(T *)
-#define array(T, N) typeof(T [N])
-@end example
-
-@noindent
-Now the declaration can be rewritten this way:
-
-@example
-array (pointer (char), 4) y;
-@end example
-
-@noindent
-Thus, @code{array (pointer (char), 4)} is the type of arrays of 4
-pointers to @code{char}.
 @end itemize
 
 @node Lvalues
@@ -6827,12 +6783,12 @@ the minimum value of variables @var{i} a
 
 However, side effects in @code{X} or @code{Y} may cause unintended
 behavior.  For example, @code{MIN (i++, j++)} will fail, incrementing
-the smaller counter twice.  A GNU C extension allows you to write safe
-macros that avoid this kind of problem (@pxref{Naming Types,,Naming an
-Expression's Type}).  However, writing @code{MIN} and @code{MAX} as
-macros also forces you to use function-call notation for a
-fundamental arithmetic operation.  Using GNU C++ extensions, you can
-write @w{@samp{int min = i <? j;}} instead.
+the smaller counter twice.  The GNU C @code{typeof} extension allows you
+to write safe macros that avoid this kind of problem (@pxref{Typeof}).
+However, writing @code{MIN} and @code{MAX} as macros also forces you to
+use function-call notation for a fundamental arithmetic operation.
+Using GNU C++ extensions, you can write @w{@samp{int min = i <? j;}}
+instead.
 
 Since @code{<?} and @code{>?} are built into the compiler, they properly
 handle expressions with side-effects;  @w{@samp{int min = i++ <? j++;}}

Re: Candidate fix for PR c/7353

[Michael Matz]

Hi,

On Mon, 7 Oct 2002, Zack Weinberg wrote:

> 	and rewrite it to use that extension instead.  Delete silly
> 	typeof example.

Why?  It might be silly (define that ;-p) but adds a clarifying example on
the effect of typeof in connection with the non-trivial syntax of
declaring types in C.


Ciao,
Michael.

Re: Candidate fix for PR c/7353

[Richard Henderson]

On Mon, Oct 07, 2002 at 11:57:33PM -0700, Zack Weinberg wrote:
> 	* c-decl.c (start_decl): It is always an error to write
> 	"typedef T = expr;".
> 	(finish_decl): Remove special case for TYPE_DECL with nonzero INIT.
> 	* cp/decl.c: Likewise.
> 
> 	* doc/extend.texi: Delete documentation of "typedef T = expr;"
> 	extension.  Move useful example there to the "typeof" section,
> 	and rewrite it to use that extension instead.  Delete silly
> 	typeof example.  Change cross-references to "Naming Types" to
> 	refer to "Typeof" instead.

This is fine with me.


r~

Re: Candidate fix for PR c/7353

[Phil Edwards]

On Tue, Oct 08, 2002 at 07:11:58AM +0100, Neil Booth wrote:
> Richard Henderson wrote:-
> 
> > > produces an ICE with all versions of GCC since 3.0.  This is an
> > > obscure, rarely-used extension, but if we're going to have it, it
> > > should work.
> > 
> > I'm for nuking it myself.
> 
> I concur.  It's really ugly.

That's putting it lightly.  Anybody writing "typedef X = 0;" needs to
be beaten about the head with a broken bottle (for punishment) and then
forced to read K&P's "The Practice of Programming" (for proper re-education).


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Candidate fix for PR c/7353

[Joseph S. Myers]

On Mon, 7 Oct 2002, Zack Weinberg wrote:

> It's a documented extension, so we might want to deprecate it for a
> release before making it go away, but since it's been broken since 3.0
> and only one person has complained, I certainly wouldn't object to
> killing it immediately.
> 
> Here's a patch to eliminate it altogether, so all alternatives will be
> on the table.  (Note that C++ generates three error messages for the
> construct with this patch, which is overkill IMO.)

You need testcases (C and C++) for removal of this feature and an entry in
the 3.3 release notes - but removing it now without a deprecation period
is OK by me (if the Release Manager approves it for this development
stage).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Candidate fix for PR c/7353

[Mark Mitchell]

--On Wednesday, October 09, 2002 09:09:06 AM +0100 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Mon, 7 Oct 2002, Zack Weinberg wrote:
>
>> It's a documented extension, so we might want to deprecate it for a
>> release before making it go away, but since it's been broken since 3.0
>> and only one person has complained, I certainly wouldn't object to
>> killing it immediately.
>>
>> Here's a patch to eliminate it altogether, so all alternatives will be
>> on the table.  (Note that C++ generates three error messages for the
>> construct with this patch, which is overkill IMO.)
>
> You need testcases (C and C++) for removal of this feature and an entry in
> the 3.3 release notes - but removing it now without a deprecation period
> is OK by me (if the Release Manager approves it for this development
> stage).

Go ahead and remove the extension, making the mods Joseph requests.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Candidate fix for PR c/7353

[Zack Weinberg]

On Wed, Oct 09, 2002 at 09:09:06AM +0100, Joseph S. Myers wrote:
> On Mon, 7 Oct 2002, Zack Weinberg wrote:
> > It's a documented extension, so we might want to deprecate it for a
> > release before making it go away, but since it's been broken since 3.0
> > and only one person has complained, I certainly wouldn't object to
> > killing it immediately.
> > 
> > Here's a patch to eliminate it altogether, so all alternatives will be
> > on the table.  (Note that C++ generates three error messages for the
> > construct with this patch, which is overkill IMO.)
> 
> You need testcases (C and C++) for removal of this feature and an entry in
> the 3.3 release notes - but removing it now without a deprecation period
> is OK by me (if the Release Manager approves it for this development
> stage).

Here is a revised patch, which has survived bootstrap and test suite,
has both C and C++ test cases, gets rid of the duplicate error message
in C++, and I put back the typeof example that some people seem to
like.  A candidate addition to the release notes is at the end.  Mark,
what do you think of this solution to the PR?

We should also do something on the 3.2 branch - thoughts?

zw

gcc:
	* c-decl.c (start_decl): Unconditionally issue error for
	'typedef foo = bar'.
	(finish_decl): Remove special case for TYPE_DECL with initializer.

	* doc/extend.texi: Delete "Naming Types" section.  Change all
	cross-references to that section to refer to "Typeof" instead.
	Add the useful safe-max()-macro example from "Naming Types" to
	"Typeof", rewritten using that extension.

gcc/cp:
	* decl.c (start_decl): Unconditionally issue error for
	'typedef foo = bar'.
	(cp_finish_decl): Remove special case for TYPE_DECL with initializer.
	(grokdeclarator): Remove redundant error for 'typedef foo = bar'.

gcc/testsuite:
	* g++.dg/ext/typedef-init.C: New test.
	* gcc.dg/typedef-init.c: New test.

===================================================================
Index: c-decl.c
--- c-decl.c	22 Sep 2002 02:03:14 -0000	1.350
+++ c-decl.c	9 Oct 2002 16:44:25 -0000
@@ -2821,15 +2821,9 @@ start_decl (declarator, declspecs, initi
     switch (TREE_CODE (decl))
       {
       case TYPE_DECL:
-	/* typedef foo = bar  means give foo the same type as bar.
-	   We haven't parsed bar yet, so `finish_decl' will fix that up.
-	   Any other case of an initialization in a TYPE_DECL is an error.  */
-	if (pedantic || list_length (declspecs) > 1)
-	  {
-	    error ("typedef `%s' is initialized",
-		   IDENTIFIER_POINTER (DECL_NAME (decl)));
-	    initialized = 0;
-	  }
+	error ("typedef `%s' is initialized",
+	       IDENTIFIER_POINTER (DECL_NAME (decl)));
+	initialized = 0;
 	break;
 
       case FUNCTION_DECL:
@@ -2988,16 +2982,7 @@ finish_decl (decl, init, asmspec_tree)
     init = 0;
 
   if (init)
-    {
-      if (TREE_CODE (decl) != TYPE_DECL)
-	store_init_value (decl, init);
-      else
-	{
-	  /* typedef foo = bar; store the type of bar as the type of foo.  */
-	  TREE_TYPE (decl) = TREE_TYPE (init);
-	  DECL_INITIAL (decl) = init = 0;
-	}
-    }
+    store_init_value (decl, init);
 
   /* Deduce size of array from initialization, if not already known */
   if (TREE_CODE (type) == ARRAY_TYPE
===================================================================
Index: cp/decl.c
--- cp/decl.c	2 Oct 2002 18:46:40 -0000	1.942
+++ cp/decl.c	9 Oct 2002 16:44:29 -0000
@@ -7290,14 +7290,8 @@ start_decl (declarator, declspecs, initi
     switch (TREE_CODE (decl))
       {
       case TYPE_DECL:
-	/* typedef foo = bar  means give foo the same type as bar.
-	   We haven't parsed bar yet, so `cp_finish_decl' will fix that up.
-	   Any other case of an initialization in a TYPE_DECL is an error.  */
-	if (pedantic || list_length (declspecs) > 1)
-	  {
-	    error ("typedef `%D' is initialized", decl);
-	    initialized = 0;
-	  }
+	error ("typedef `%D' is initialized", decl);
+	initialized = 0;
 	break;
 
       case FUNCTION_DECL:
@@ -8156,12 +8150,6 @@ cp_finish_decl (decl, init, asmspec_tree
   /* Take care of TYPE_DECLs up front.  */
   if (TREE_CODE (decl) == TYPE_DECL)
     {
-      if (init && DECL_INITIAL (decl))
-	{
-	  /* typedef foo = bar; store the type of bar as the type of foo.  */
-	  TREE_TYPE (decl) = type = TREE_TYPE (init);
-	  DECL_INITIAL (decl) = init = NULL_TREE;
-	}
       if (type != error_mark_node
 	  && IS_AGGR_TYPE (type) && DECL_NAME (decl))
 	{
@@ -11364,9 +11352,6 @@ grokdeclarator (declarator, declspecs, d
 
       bad_specifiers (decl, "type", virtualp, quals != NULL_TREE,
 		      inlinep, friendp, raises != NULL_TREE);
-
-      if (initialized)
-	error ("typedef declaration includes an initializer");
 
       return decl;
     }
===================================================================
Index: doc/extend.texi
--- doc/extend.texi	27 Sep 2002 13:30:07 -0000	1.104
+++ doc/extend.texi	9 Oct 2002 16:44:31 -0000
@@ -427,7 +427,6 @@ extensions, accepted by GCC in C89 mode 
 * Labels as Values::    Getting pointers to labels, and computed gotos.
 * Nested Functions::    As in Algol and Pascal, lexical scoping of functions.
 * Constructing Calls::	Dispatching a call to another function.
-* Naming Types::        Giving a name to the type of some expression.
 * Typeof::              @code{typeof}: referring to the type of an expression.
 * Lvalues::             Using @samp{?:}, @samp{,} and casts in lvalues.
 * Conditionals::        Omitting the middle operand of a @samp{?:} expression.
@@ -538,8 +537,7 @@ the value of an enumeration constant, th
 the initial value of a static variable.
 
 If you don't know the type of the operand, you can still do this, but you
-must use @code{typeof} (@pxref{Typeof}) or type naming (@pxref{Naming
-Types}).
+must use @code{typeof} (@pxref{Typeof}).
 
 Statement expressions are not supported fully in G++, and their fate
 there is unclear.  (It is possible that they will become fully supported
@@ -888,29 +886,6 @@ the containing function.  You should spe
 returned by @code{__builtin_apply}.
 @end deftypefn
 
-@node Naming Types
-@section Naming an Expression's Type
-@cindex naming types
-
-You can give a name to the type of an expression using a @code{typedef}
-declaration with an initializer.  Here is how to define @var{name} as a
-type name for the type of @var{exp}:
-
-@example
-typedef @var{name} = @var{exp};
-@end example
-
-This is useful in conjunction with the statements-within-expressions
-feature.  Here is how the two together can be used to define a safe
-``maximum'' macro that operates on any arithmetic type:
-
-@example
-#define max(a,b) \
-  (@{typedef _ta = (a), _tb = (b);  \
-    _ta _a = (a); _tb _b = (b);     \
-    _a > _b ? _a : _b; @})
-@end example
-
 @cindex underscores in variables in macros
 @cindex @samp{_} in variables in macros
 @cindex local variables in macros
@@ -962,6 +937,20 @@ A @code{typeof}-construct can be used an
 used.  For example, you can use it in a declaration, in a cast, or inside
 of @code{sizeof} or @code{typeof}.
 
+@code{typeof} is often useful in conjunction with the
+statements-within-expressions feature.  Here is how the two together can
+be used to define a safe ``maximum'' macro that operates on any
+arithmetic type and evaluates each of its arguments exactly once:
+
+@example
+#define max(a,b) \
+  (@{ typeof (a) _a = (a); \
+      typeof (b) _b = (b); \
+    _a > _b ? _a : _b; @})
+@end example
+
+Some more examples of the use of @code{typeof}:
+
 @itemize @bullet
 @item
 This declares @code{y} with the type of what @code{x} points to.
@@ -6827,12 +6816,12 @@ the minimum value of variables @var{i} a
 
 However, side effects in @code{X} or @code{Y} may cause unintended
 behavior.  For example, @code{MIN (i++, j++)} will fail, incrementing
-the smaller counter twice.  A GNU C extension allows you to write safe
-macros that avoid this kind of problem (@pxref{Naming Types,,Naming an
-Expression's Type}).  However, writing @code{MIN} and @code{MAX} as
-macros also forces you to use function-call notation for a
-fundamental arithmetic operation.  Using GNU C++ extensions, you can
-write @w{@samp{int min = i <? j;}} instead.
+the smaller counter twice.  The GNU C @code{typeof} extension allows you
+to write safe macros that avoid this kind of problem (@pxref{Typeof}).
+However, writing @code{MIN} and @code{MAX} as macros also forces you to
+use function-call notation for a fundamental arithmetic operation.
+Using GNU C++ extensions, you can write @w{@samp{int min = i <? j;}}
+instead.
 
 Since @code{<?} and @code{>?} are built into the compiler, they properly
 handle expressions with side-effects;  @w{@samp{int min = i++ <? j++;}}
===================================================================
Index: testsuite/g++.dg/ext/typedef-init.C
--- testsuite/g++.dg/ext/typedef-init.C	1 Jan 1970 00:00:00 -0000
+++ testsuite/g++.dg/ext/typedef-init.C	9 Oct 2002 16:44:31 -0000
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-fpermissive" } // suppress default -pedantic-errors */
+
+/* This code used to be a legitimate, if dubious, extension.  However,
+   it's been broken since GCC 3.0 (caused ICE) and we have now removed
+   the extension.  See PR c/7353.
+
+   C++ issues a warning in addition to the error, since this construct
+   appears to be a case of implicit int (forbidden in std. C++) until
+   we get to the equals sign.  */
+
+typedef A = 0;  /* { dg-error "initialized" "typedef A = B" } */
+                /* { dg-warning "no type" "also warns" { target *-*-* } 12 } */
+A a;            /* { dg-bogus "" "no error cascade" } */
===================================================================
Index: testsuite/gcc.dg/typedef-init.c
--- testsuite/gcc.dg/typedef-init.c	1 Jan 1970 00:00:00 -0000
+++ testsuite/gcc.dg/typedef-init.c	9 Oct 2002 16:44:32 -0000
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu89" } // suppress default -pedantic-errors */
+
+/* This code used to be a legitimate, if dubious, extension.  However,
+   it's been broken since GCC 3.0 (caused ICE) and we have now removed
+   the extension.  See PR c/7353.  */
+
+typedef A = 0;  /* { dg-error "initialized" "typedef A = B" } */
+A a;            /* { dg-bogus "" "no error cascade" } */
===================================================================
Index: gcc-3.3/changes.html
--- gcc-3.3/changes.html	2 Oct 2002 17:40:48 -0000	1.8
+++ gcc-3.3/changes.html	9 Oct 2002 16:55:19 -0000
@@ -35,7 +35,17 @@
     <li>The DWARF (version 1) debugging format has been deprecated and 
         will be removed in a future version of GCC.  Version 2 of the 
 	DWARF debugging format will continue to be supported for the
-        forseeable future.</li>
+        foreseeable future.</li>
+
+    <li>The C and Objective C compilers no longer accept the "Naming
+        Types" extension (<code>typedef foo = bar</code>); it was
+        already unavailable in C++.  Code which uses it will need to
+        be changed to use the "typeof" extension instead:
+        <code>typedef typeof(bar) foo</code>.  (We have removed this
+        extension without a period of deprecation because it has
+        caused the compiler to crash since version 3.0 and no one
+        noticed until very recently.  Thus we conclude it is not in
+        widespread use.)</li>
   </ul>
 
 

Re: Candidate fix for PR c/7353

[Mark Mitchell]

> We should also do something on the 3.2 branch - thoughts?

Apply the same patch there, or as close as you can get.  The crash is
a regression, and it's better to tell people this no longer works than
to simply crash.

This is pretty cavalier treatement for a documented extension, but this
is a special case (the total breakage for a long time).

You might note that you can do:

  typedef typeof (0) T;

instead of:

  typedef T = 0;

in your docs somewhere.  That works in GNU C++ as well, by the way.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Candidate fix for PR c/7353

[Zack Weinberg]

On Wed, Oct 09, 2002 at 09:48:32AM -0700, Mark Mitchell wrote:
> --On Wednesday, October 09, 2002 09:09:06 AM +0100 "Joseph S. Myers" wrote:
> >You need testcases (C and C++) for removal of this feature and an entry in
> >the 3.3 release notes - but removing it now without a deprecation period
> >is OK by me (if the Release Manager approves it for this development
> >stage).
> 
> Go ahead and remove the extension, making the mods Joseph requests.

Oops, crossed wires.  I will go ahead and check in on the mainline,
the patch I just sent.  I'd still appreciate an opinion about what if
anything should be done for 3.2.1.

zw

Re: Candidate fix for PR c/7353

[Zack Weinberg]

On Wed, Oct 09, 2002 at 09:59:21AM -0700, Mark Mitchell wrote:
> >We should also do something on the 3.2 branch - thoughts?
> 
> Apply the same patch there, or as close as you can get.  The crash is
> a regression, and it's better to tell people this no longer works than
> to simply crash.

Okay.  The patch applies with no modifications to 3.2; I am running a
bootstrap now.  I'll check it in on both branches at the same time,
later today, and close the PR.

> You might note that you can do:
> 
>  typedef typeof (0) T;
> 
> instead of:
> 
>  typedef T = 0;
> 
> in your docs somewhere.  That works in GNU C++ as well, by the way.

Revised patch for doc/extend.texi follows.  This was already in the
release notes.

zw

===================================================================
Index: doc/extend.texi
--- doc/extend.texi	27 Sep 2002 13:30:07 -0000	1.104
+++ doc/extend.texi	9 Oct 2002 18:22:10 -0000
@@ -427,7 +427,6 @@ extensions, accepted by GCC in C89 mode 
 * Labels as Values::    Getting pointers to labels, and computed gotos.
 * Nested Functions::    As in Algol and Pascal, lexical scoping of functions.
 * Constructing Calls::	Dispatching a call to another function.
-* Naming Types::        Giving a name to the type of some expression.
 * Typeof::              @code{typeof}: referring to the type of an expression.
 * Lvalues::             Using @samp{?:}, @samp{,} and casts in lvalues.
 * Conditionals::        Omitting the middle operand of a @samp{?:} expression.
@@ -538,8 +537,7 @@ the value of an enumeration constant, th
 the initial value of a static variable.
 
 If you don't know the type of the operand, you can still do this, but you
-must use @code{typeof} (@pxref{Typeof}) or type naming (@pxref{Naming
-Types}).
+must use @code{typeof} (@pxref{Typeof}).
 
 Statement expressions are not supported fully in G++, and their fate
 there is unclear.  (It is possible that they will become fully supported
@@ -888,29 +886,6 @@ the containing function.  You should spe
 returned by @code{__builtin_apply}.
 @end deftypefn
 
-@node Naming Types
-@section Naming an Expression's Type
-@cindex naming types
-
-You can give a name to the type of an expression using a @code{typedef}
-declaration with an initializer.  Here is how to define @var{name} as a
-type name for the type of @var{exp}:
-
-@example
-typedef @var{name} = @var{exp};
-@end example
-
-This is useful in conjunction with the statements-within-expressions
-feature.  Here is how the two together can be used to define a safe
-``maximum'' macro that operates on any arithmetic type:
-
-@example
-#define max(a,b) \
-  (@{typedef _ta = (a), _tb = (b);  \
-    _ta _a = (a); _tb _b = (b);     \
-    _a > _b ? _a : _b; @})
-@end example
-
 @cindex underscores in variables in macros
 @cindex @samp{_} in variables in macros
 @cindex local variables in macros
@@ -962,6 +937,21 @@ A @code{typeof}-construct can be used an
 used.  For example, you can use it in a declaration, in a cast, or inside
 of @code{sizeof} or @code{typeof}.
 
+@code{typeof} is often useful in conjunction with the
+statements-within-expressions feature.  Here is how the two together can
+be used to define a safe ``maximum'' macro that operates on any
+arithmetic type and evaluates each of its arguments exactly once:
+
+@example
+#define max(a,b) \
+  (@{ typeof (a) _a = (a); \
+      typeof (b) _b = (b); \
+    _a > _b ? _a : _b; @})
+@end example
+
+@noindent
+Some more examples of the use of @code{typeof}:
+
 @itemize @bullet
 @item
 This declares @code{y} with the type of what @code{x} points to.
@@ -1011,6 +1001,26 @@ Thus, @code{array (pointer (char), 4)} i
 pointers to @code{char}.
 @end itemize
 
+@emph{Compatibility Note:} In addition to @code{typeof}, GCC 2 supported
+a more limited extension which permitted one to write
+
+@example
+typedef @var{T} = @var{expr};
+@end example
+
+@noindent
+with the effect of declaring @var{T} to have the type of the expression
+@var{expr}.  This extension does not work with GCC 3 (versions between
+3.0 and 3.2 will crash; 3.2.1 and later give an error).  Code which
+relies on it should be rewritten to use @code{typeof}:
+
+@example
+typedef typeof(@var{expr}) @var{T};
+@end example
+
+@noindent
+This will work with all versions of GCC@.
+
 @node Lvalues
 @section Generalized Lvalues
 @cindex compound expressions as lvalues
@@ -6827,12 +6837,12 @@ the minimum value of variables @var{i} a
 
 However, side effects in @code{X} or @code{Y} may cause unintended
 behavior.  For example, @code{MIN (i++, j++)} will fail, incrementing
-the smaller counter twice.  A GNU C extension allows you to write safe
-macros that avoid this kind of problem (@pxref{Naming Types,,Naming an
-Expression's Type}).  However, writing @code{MIN} and @code{MAX} as
-macros also forces you to use function-call notation for a
-fundamental arithmetic operation.  Using GNU C++ extensions, you can
-write @w{@samp{int min = i <? j;}} instead.
+the smaller counter twice.  The GNU C @code{typeof} extension allows you
+to write safe macros that avoid this kind of problem (@pxref{Typeof}).
+However, writing @code{MIN} and @code{MAX} as macros also forces you to
+use function-call notation for a fundamental arithmetic operation.
+Using GNU C++ extensions, you can write @w{@samp{int min = i <? j;}}
+instead.
 
 Since @code{<?} and @code{>?} are built into the compiler, they properly
 handle expressions with side-effects;  @w{@samp{int min = i++ <? j++;}}

Re: Candidate fix for PR c/7353

[Mike Stump]

On Monday, October 7, 2002, at 11:11 PM, Neil Booth wrote:
> Richard Henderson wrote:-
>
>>> produces an ICE with all versions of GCC since 3.0.  This is an
>>> obscure, rarely-used extension, but if we're going to have it, it
>>> should work.
>>
>> I'm for nuking it myself.
>
> I concur.  It's really ugly.

I know about typeof, but never knew about this one, I'd vote for nuking 
it, maybe give an error message that explain the way to write it 
instead.
If the C++ world, it would be -fpermissive, though, I don't think C has 
this flag.  We could add it back in a . release, if a lot of important 
people complain (I'm betting they won't).

Re: Candidate fix for PR c/7353

[Mark Mitchell]

--On Wednesday, October 09, 2002 11:22:14 AM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> On Wed, Oct 09, 2002 at 09:59:21AM -0700, Mark Mitchell wrote:
>> > We should also do something on the 3.2 branch - thoughts?
>>
>> Apply the same patch there, or as close as you can get.  The crash is
>> a regression, and it's better to tell people this no longer works than
>> to simply crash.
>
> Okay.  The patch applies with no modifications to 3.2; I am running a
> bootstrap now.  I'll check it in on both branches at the same time,
> later today, and close the PR.

Cool-o.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Candidate fix for PR c/7353

[Jason Merrill]

This patch causes us to no longer give an error for

  struct A {
    typedef int B = 0;
  };

this is a regression.

Jason

Re: Candidate fix for PR c/7353

[Zack Weinberg]

On Fri, Nov 01, 2002 at 01:55:48AM -0500, Jason Merrill wrote:
> This patch causes us to no longer give an error for
> 
>   struct A {
>     typedef int B = 0;
>   };

Huh?

$ ./cc1 -quiet test.c
test.c:2: error: parse error before "typedef"
test.c:2: warning: no semicolon at end of struct or union

$ ./cc1plus -quiet test.c
test.c:2: error: ISO C++ forbids declaration of `B' with no type

Not the *best* diagnostics, but I don't feel it's worth trying to get
good diagnostics out of the old parser.

zw

Re: Candidate fix for PR c/7353

[Jason Merrill]

On Fri, 1 Nov 2002 09:45:18 -0800, Zack Weinberg <zack@codesourcery.com> wrote:

> On Fri, Nov 01, 2002 at 01:55:48AM -0500, Jason Merrill wrote:
>> This patch causes us to no longer give an error for
>> 
>>   struct A {
>>     typedef int B = 0;
>>   };

> Huh?
>
> $ ./cc1plus -quiet test.c
> test.c:2: error: ISO C++ forbids declaration of `B' with no type

I don't get this error.  It does say 'int', after all...

Jason

Re: Candidate fix for PR c/7353

[Paolo Carlini]

Jason Merrill wrote:

>>$ ./cc1plus -quiet test.c
>>test.c:2: error: ISO C++ forbids declaration of `B' with no type
>>    
>>
>I don't get this error.  It does say 'int', after all...
>
Neither I, with a compiler built from sources checked out minutes ago.

Ciao, Paolo.

Re: Candidate fix for PR c/7353

[Zack Weinberg]

On Fri, Nov 01, 2002 at 01:38:29PM -0500, Jason Merrill wrote:
> On Fri, 1 Nov 2002 09:45:18 -0800, Zack Weinberg <zack@codesourcery.com> wrote:
> 
> > On Fri, Nov 01, 2002 at 01:55:48AM -0500, Jason Merrill wrote:
> >> This patch causes us to no longer give an error for
> >> 
> >>   struct A {
> >>     typedef int B = 0;
> >>   };
> 
> > Huh?
> >
> > $ ./cc1plus -quiet test.c
> > test.c:2: error: ISO C++ forbids declaration of `B' with no type
> 
> I don't get this error.  It does say 'int', after all...

Oof, sorry, I skimmed right past the 'int' when I retyped the test
case.

In the C++ front end, field declarations don't go through start_decl
so they get missed.  This isn't a problem in C because you can't put
a typedef inside an aggregate at all, in that language.

I'm testing this patch for the bug.

zw

cp:
	PR c/7353 redux
	* decl2.c (grokfield): Reject TYPE_DECLs with initializers.

testsuite:
	* g++.dg/ext/typedef-init.C, gcc.dg/typedef-init.C:
	Add some more cases.

===================================================================
Index: cp/decl2.c
--- cp/decl2.c	31 Oct 2002 16:07:31 -0000	1.569
+++ cp/decl2.c	1 Nov 2002 19:46:35 -0000
@@ -915,7 +915,13 @@ grokfield (declarator, declspecs, init, 
     /* friend or constructor went bad.  */
     return value;
   if (TREE_TYPE (value) == error_mark_node)
-    return error_mark_node;  
+    return error_mark_node;
+
+  if (TREE_CODE (value) == TYPE_DECL && init)
+    {
+      error ("typedef `%D' is initialized (use __typeof__ instead)", value);
+      init = NULL_TREE;
+    }
 
   /* Pass friendly classes back.  */
   if (TREE_CODE (value) == VOID_TYPE)
===================================================================
Index: testsuite/g++.dg/ext/typedef-init.C
--- testsuite/g++.dg/ext/typedef-init.C	9 Oct 2002 21:27:38 -0000	1.1
+++ testsuite/g++.dg/ext/typedef-init.C	1 Nov 2002 19:46:36 -0000
@@ -5,10 +5,29 @@
    it's been broken since GCC 3.0 (caused ICE) and we have now removed
    the extension.  See PR c/7353.
 
-   C++ issues a warning in addition to the error, since this construct
-   appears to be a case of implicit int (forbidden in std. C++) until
-   we get to the equals sign.  */
-
-typedef A = 0;  /* { dg-error "initialized" "typedef A = B" } */
-                /* { dg-warning "no type" "also warns" { target *-*-* } 12 } */
-A a;            /* { dg-bogus "" "no error cascade" } */
+   For cases A and C, C++ issues a warning in addition to the error,
+   since this construct appears to be a case of implicit int
+   (forbidden in std. C++) until we get to the equals sign.  */
+
+/* Case A: just the bare name = initializer.  */
+
+typedef A = 0;  /* { dg-error "initialized" "A" } */
+                /* { dg-warning "no type" "A warns" { target *-*-* } 14 } */
+A a;            /* { dg-bogus "" "A error cascade" } */
+
+/* Case B: with a type also.  */
+
+typedef int B = 0;  /* { dg-error "initialized" "B" } */
+B b;		    /* { dg-bogus "" "B error cascade" } */
+
+/* C and D are the same as A and B, but wrapped in a structure;
+   field declarations go by a different code path in C++ (ick).  */
+
+struct S {
+  typedef C = 0; /* { dg-error "initialized" "C" } */
+                 /* { dg-warning "no type" "C warns" { target *-*-* } 27 } */
+  C c;		 /* { dg-bogus "" "C error cascade" } */
+
+  typedef int D = 0; /* { dg-error "initialized" "D" } */
+  D d;		     /* { dg-bogus "" "D error cascade" } */
+};
===================================================================
Index: testsuite/gcc.dg/typedef-init.c
--- testsuite/gcc.dg/typedef-init.c	9 Oct 2002 21:27:38 -0000	1.1
+++ testsuite/gcc.dg/typedef-init.c	1 Nov 2002 19:46:37 -0000
@@ -5,5 +5,12 @@
    it's been broken since GCC 3.0 (caused ICE) and we have now removed
    the extension.  See PR c/7353.  */
 
-typedef A = 0;  /* { dg-error "initialized" "typedef A = B" } */
-A a;            /* { dg-bogus "" "no error cascade" } */
+/* Case A: just the bare name = initializer.  */
+
+typedef A = 0;  /* { dg-error "initialized" "A" } */
+A a;            /* { dg-bogus "" "A error cascade" } */
+
+/* Case B: with a type also.  */
+
+typedef int B = 0;  /* { dg-error "initialized" "B" } */
+B b;		    /* { dg-bogus "" "B error cascade" } */

Re: Candidate fix for PR c/7353

[Mark Mitchell]

> I'm testing this patch for the bug.

The patch is fine when you're done testing.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com