From: Akim Demaille <akim@epita.fr>
To: Matthias Klose <doko@cs.tu-berlin.de>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>,
debian-gcc@lists.debian.org.mark, gcc@gcc.gnu.org,
gcc-patches@gcc.gnu.org, zack@codesourcery.com,
Bison Bugs <bug-bison@gnu.org>
Subject: Re: gcc-3_2-branch bootstrap failure when using bison-1.50
Date: Mon, 14 Oct 2002 06:46:00 -0000 [thread overview]
Message-ID: <mv4r8etmm3t.fsf@nostromo.lrde.epita.fr> (raw)
In-Reply-To: <15785.63316.79215.785175@gargle.gargle.HOWL>
Please people, use the proper mail addresses: bug-bison.
----------------------------------------------------------------------
Kaveh R. Ghazi writes:
> > From: Matthias Klose <doko at cs dot tu-berlin dot de>
> >
> > Bootrapping the gcc-3_2-branch using bison-1.50 is broken. Reverting
> > back to bison-1.35 works. HEAD does work well using bison-1.50
> >
> > cd /build/gcc/gcc-3.2-3.2.1ds3/src/gcc && \
> > if bison -o c-p$$.c c-parse.y; then \
> > test -f c-p$$.output && mv -f c-p$$.output c-parse.output ; \
> > mv -f c-p$$.c c-parse.c ; \
> > else \
> > rm -f c-p$$.* ; \
> > false ; \
> > fi
> > c-parse.y:1432.2-1436.10: type clash (`' `ttype') on default action
>
> I checked into this one, patches were submitted for the trunk and
> installed back in June for these problems. E.g. see:
> http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01614.html
>
> I guess this and other similar patches for the other .y files weren't
> backported to the 3.2 branch. This shouldn't be too bad since the
> actual GCC-3.2.x release tar file will contain the necessary bison
> output of a suitable bison version. In the mean time, I suggest just
> not using bison-1.50 for testing 3.2.x CVS snapshots.
it's difficult to check the branch, if you only have one bison version
available for building (Debian unstable).
> I'll leave it to our release manager to decide if this issue warrants
> backporting the relevant patches or not.
I would appreciate it.
Attached are backports of patches I found on the mailing
lists (c, cp and java). Checked today's CVS with 1.35, CVS with the
patch attached with 1.35 and with 1.50. cp and java don't show
regressions. for c:
- CVS and CVS+patch, both bison-1.35: no regressions.
- bison-1.35 and bison-1.50, both CVS+patch:
--- test-summary-1.35 2002-10-14 00:16:08.000000000 +0200
+++ test-summary-1.50 2002-10-13 13:55:39.000000000 +0200
@@ -39,11 +39,43 @@
FAIL: gcc.c-torture/compile/20020927-1.c, -O3 -g
FAIL: gcc.c-torture/execute/loop-2e.c execution, -Os
FAIL: gcc.c-torture/execute/loop-3c.c execution, -Os
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 69)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 72)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 74)
+FAIL: gcc.dg/noncompile/920923-1.c (test for errors, line 77)
=== gcc Summary ===
-# of expected passes 18721
-# of unexpected failures 6
+# of expected passes 18689
+# of unexpected failures 38
# of expected failures 66
# of unsupported tests 43
I could not find any other patch on the mailing lists. Any idea or help?
In http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01682.html Zack
mentions that he collected the patches.
Attached are the backported patches. Note, that all whitespace changes
are removed in these patches.
2002-10-13 Matthias Klose <doko@debian.org>
* Backport, without whitespace change:
2002-06-19 Akim Demaille <akim@epita.fr>
* c-parse.in (initelt: identifier ':' initval): Add an empty
action to fix a type clash.
(aliasdecl, classdef): Add the missing closing `;'.
--- gcc/c-parse.in.orig 2002-09-04 00:46:53.000000000 +0200
+++ gcc/c-parse.in 2002-10-13 09:33:10.000000000 +0200
@@ -1527,6 +1527,7 @@
if (pedantic)
pedwarn ("obsolete use of designated initializer with `:'"); }
initval
+ {}
| initval
;
@@ -2700,12 +2701,14 @@
{
objc_declare_class ($2);
}
+ ;
aliasdecl:
ALIAS identifier identifier ';'
{
objc_declare_alias ($2, $3);
}
+ ;
classdef:
INTERFACE identifier protocolrefs '{'
2002-10-13 Matthias Klose <doko@debian.org>
* Backport, without whitespace change:
2002-06-19 Akim Demaille <akim@epita.fr>
* parse.y (TYPENAME): Rename as tTYPENAME to avoid the clash with
decl.h's TYPENAME.
* spew.c, lex.c: Adjust.
* parse.y (explicit_instantiation): Add empty action to override
the default $$ = $1 where it introduces a type clash.
--- gcc/cp/lex.c.orig 2002-05-23 21:12:23.000000000 +0200
+++ gcc/cp/lex.c 2002-10-13 09:37:59.000000000 +0200
@@ -90,10 +90,11 @@
int warn_traditional = 0;
int flag_digraphs = 1;
-/* the declaration found for the last IDENTIFIER token read in.
- yylex must look this up to detect typedefs, which get token type TYPENAME,
- so it is left around in case the identifier is not a typedef but is
- used in a context which makes it a reference to a variable. */
+/* the declaration found for the last IDENTIFIER token read in. yylex
+ must look this up to detect typedefs, which get token type
+ tTYPENAME, so it is left around in case the identifier is not a
+ typedef but is used in a context which makes it a reference to a
+ variable. */
tree lastiddecl;
/* Array for holding counts of the numbers of tokens seen. */
@@ -739,7 +740,7 @@
switch (yychar)
{
case IDENTIFIER:
- case TYPENAME:
+ case tTYPENAME:
case TYPESPEC:
case PTYPENAME:
case PFUNCNAME:
@@ -977,7 +978,7 @@
if ((yychar > 255
&& yychar != SCSPEC
&& yychar != IDENTIFIER
- && yychar != TYPENAME
+ && yychar != tTYPENAME
&& yychar != CV_QUALIFIER
&& yychar != SELFNAME)
|| yychar == 0 /* EOF */)
--- gcc/cp/parse.y.orig 2002-09-04 00:47:14.000000000 +0200
+++ gcc/cp/parse.y 2002-10-13 09:37:59.000000000 +0200
@@ -253,7 +253,7 @@
/* All identifiers that are declared typedefs in the current block.
In some contexts, they are treated just like IDENTIFIER,
but they can also serve as typespecs in declarations. */
-%token TYPENAME
+%token tTYPENAME
%token SELFNAME
/* A template function. */
@@ -315,7 +315,7 @@
%nonassoc IF
%nonassoc ELSE
-%left IDENTIFIER PFUNCNAME TYPENAME SELFNAME PTYPENAME SCSPEC TYPESPEC CV_QUALIFIER ENUM AGGR ELLIPSIS TYPEOF SIGOF OPERATOR NSNAME TYPENAME_KEYWORD ATTRIBUTE
+%left IDENTIFIER PFUNCNAME tTYPENAME SELFNAME PTYPENAME SCSPEC TYPESPEC CV_QUALIFIER ENUM AGGR ELLIPSIS TYPEOF SIGOF OPERATOR NSNAME TYPENAME_KEYWORD ATTRIBUTE
%left '{' ',' ';'
@@ -345,7 +345,7 @@
%type <code> unop
-%type <ttype> identifier IDENTIFIER TYPENAME CONSTANT expr nonnull_exprlist
+%type <ttype> identifier IDENTIFIER tTYPENAME CONSTANT expr nonnull_exprlist
%type <ttype> PFUNCNAME maybe_identifier
%type <ttype> paren_expr_or_null nontrivial_exprlist SELFNAME
%type <ttype> expr_no_commas expr_no_comma_rangle
@@ -994,7 +994,7 @@
identifier:
IDENTIFIER
- | TYPENAME
+ | tTYPENAME
| SELFNAME
| PTYPENAME
| NSNAME
@@ -1031,17 +1031,21 @@
{ do_type_instantiation ($4.t, $1, 1);
yyungetc (';', 1); }
end_explicit_instantiation
+ {}
| SCSPEC TEMPLATE begin_explicit_instantiation typed_declspecs
declarator
{ tree specs = strip_attrs ($4.t);
do_decl_instantiation (specs, $5, $1); }
end_explicit_instantiation
+ {}
| SCSPEC TEMPLATE begin_explicit_instantiation notype_declarator
{ do_decl_instantiation (NULL_TREE, $4, $1); }
end_explicit_instantiation
+ {}
| SCSPEC TEMPLATE begin_explicit_instantiation constructor_declarator
{ do_decl_instantiation (NULL_TREE, $4, $1); }
end_explicit_instantiation
+ {}
;
begin_explicit_instantiation:
@@ -1060,7 +1064,7 @@
PTYPENAME '<' template_arg_list_opt template_close_bracket
.finish_template_type
{ $$ = $5; }
- | TYPENAME '<' template_arg_list_opt template_close_bracket
+ | tTYPENAME '<' template_arg_list_opt template_close_bracket
.finish_template_type
{ $$ = $5; }
| self_template_type
@@ -1532,7 +1536,7 @@
unqualified_id:
notype_unqualified_id
- | TYPENAME
+ | tTYPENAME
| SELFNAME
;
@@ -2767,7 +2771,7 @@
after_type_declarator maybeasm maybe_attribute maybe_init
{ $$ = parse_field0 ($1, $<ftype>0.t, $<ftype>0.lookups,
$3, $2, $4); }
- | TYPENAME ':' expr_no_commas maybe_attribute
+ | tTYPENAME ':' expr_no_commas maybe_attribute
{ $$ = parse_bitfield0 ($1, $<ftype>0.t, $<ftype>0.lookups,
$4, $3); }
;
@@ -2790,7 +2794,7 @@
after_type_component_declarator:
after_type_declarator maybeasm maybe_attribute maybe_init
{ $$ = parse_field ($1, $3, $2, $4); }
- | TYPENAME ':' expr_no_commas maybe_attribute
+ | tTYPENAME ':' expr_no_commas maybe_attribute
{ $$ = parse_bitfield ($1, $4, $3); }
;
@@ -3062,7 +3066,7 @@
;
type_name:
- TYPENAME
+ tTYPENAME
| SELFNAME
| template_type %prec EMPTY
;
@@ -3086,7 +3090,7 @@
/* Why the @#$%^& do type_name and notype_identifier need to be expanded
inline here?!? (jason) */
nested_name_specifier_1:
- TYPENAME SCOPE
+ tTYPENAME SCOPE
{
if (TREE_CODE ($1) == IDENTIFIER_NODE)
{
@@ -3172,7 +3176,7 @@
/* This needs to return a TYPE_DECL for simple names so that we don't
forget what name was used. */
typename_sub2:
- TYPENAME SCOPE
+ tTYPENAME SCOPE
{
if (TREE_CODE ($1) != TYPE_DECL)
$$ = lastiddecl;
@@ -3610,7 +3614,7 @@
{ finish_label_stmt ($1); }
| PTYPENAME ':'
{ finish_label_stmt ($1); }
- | TYPENAME ':'
+ | tTYPENAME ':'
{ finish_label_stmt ($1); }
| SELFNAME ':'
{ finish_label_stmt ($1); }
--- gcc/cp/spew.c.orig 2002-03-02 00:38:50.000000000 +0100
+++ gcc/cp/spew.c 2002-10-13 09:37:59.000000000 +0200
@@ -141,10 +141,11 @@
static tree last_token_id;
/* From lex.c: */
-/* the declaration found for the last IDENTIFIER token read in.
- yylex must look this up to detect typedefs, which get token type TYPENAME,
- so it is left around in case the identifier is not a typedef but is
- used in a context which makes it a reference to a variable. */
+/* the declaration found for the last IDENTIFIER token read in. yylex
+ must look this up to detect typedefs, which get token type
+ tTYPENAME, so it is left around in case the identifier is not a
+ typedef but is used in a context which makes it a reference to a
+ variable. */
extern tree lastiddecl; /* let our brains leak out here too */
extern int yychar; /* the lookahead symbol */
extern YYSTYPE yylval; /* the semantic value of the */
@@ -628,11 +629,11 @@
if (t && t == decl)
return SELFNAME;
- return TYPENAME;
+ return tTYPENAME;
}
/* token[0] == AGGR (struct/union/enum)
- Thus, token[1] is either a TYPENAME or a TYPENAME_DEFN.
+ Thus, token[1] is either a tTYPENAME or a TYPENAME_DEFN.
If token[2] == '{' or ':' then it's TYPENAME_DEFN.
It's also a definition if it's a forward declaration (as in 'struct Foo;')
which we can tell if token[2] == ';' *and* token[-1] != FRIEND or NEW. */
@@ -644,7 +645,7 @@
scan_tokens (2);
yc1 = nth_token (1)->yychar;
- if (yc1 != TYPENAME && yc1 != IDENTIFIER && yc1 != PTYPENAME)
+ if (yc1 != tTYPENAME && yc1 != IDENTIFIER && yc1 != PTYPENAME)
return;
yc2 = nth_token (2)->yychar;
if (yc2 == ';')
@@ -659,7 +660,7 @@
switch (yc1)
{
- case TYPENAME:
+ case tTYPENAME:
nth_token (1)->yychar = TYPENAME_DEFN;
break;
case PTYPENAME:
@@ -757,7 +758,7 @@
break;
}
case IDENTIFIER_DEFN:
- case TYPENAME:
+ case tTYPENAME:
case TYPENAME_DEFN:
case PTYPENAME:
case PTYPENAME_DEFN:
@@ -897,7 +898,7 @@
yyc = identifier_type (trrr);
switch(yyc)
{
- case TYPENAME:
+ case tTYPENAME:
case SELFNAME:
case NSNAME:
case PTYPENAME:
@@ -1448,7 +1449,7 @@
{
if (yy<256)
fprintf (stderr, "->%d < %c >\n", lineno, yy);
- else if (yy == IDENTIFIER || yy == TYPENAME)
+ else if (yy == IDENTIFIER || yy == tTYPENAME)
{
const char *id;
if (TREE_CODE (yylval.ttype) == IDENTIFIER_NODE)
2002-10-13 Matthias Klose <doko@debian.org>
* Backport, without whitespace change:
2002-06-10 Akim Demaille <akim@epita.fr>
* parse.y (interface_type_list, class_member_declaration)
(unary_expression_not_plus_minus): Remove duplicate %type.
Whitespace changes.
2002-06-13 Akim Demaille <akim@epita.fr>
* parse.y (class_declaration, interface_declaration): Make sure
all their rules have an action, in order to avoid meaningless `$$
= $1' and their type clashes.
* parse.y (catch_clause): Terminate with `;'.
--- gcc/java/parse.y.orig 2002-10-13 10:20:40.000000000 +0200
+++ gcc/java/parse.y 2002-10-13 11:05:32.000000000 +0200
@@ -522,12 +522,11 @@
%type <node> type_declaration compilation_unit
field_declaration method_declaration extends_interfaces
interfaces interface_type_list
- class_member_declaration
import_declarations package_declaration
type_declarations interface_body
interface_member_declaration constant_declaration
interface_member_declarations interface_type
- abstract_method_declaration interface_type_list
+ abstract_method_declaration
%type <node> class_body_declaration class_member_declaration
static_initializer constructor_declaration block
%type <node> class_body_declarations constructor_header
@@ -556,7 +555,7 @@
post_increment_expression post_decrement_expression
unary_expression_not_plus_minus unary_expression
pre_increment_expression pre_decrement_expression
- unary_expression_not_plus_minus cast_expression
+ cast_expression
multiplicative_expression additive_expression
shift_expression relational_expression
equality_expression and_expression
@@ -852,9 +851,11 @@
modifiers CLASS_TK identifier super interfaces
{ create_class ($1, $3, $4, $5); }
class_body
+ {;}
| CLASS_TK identifier super interfaces
{ create_class (0, $2, $3, $4); }
class_body
+ {;}
| modifiers CLASS_TK error
{yyerror ("Missing class name"); RECOVER;}
| CLASS_TK error
@@ -1285,15 +1286,19 @@
INTERFACE_TK identifier
{ create_interface (0, $2, NULL_TREE); }
interface_body
+ { ; }
| modifiers INTERFACE_TK identifier
{ create_interface ($1, $3, NULL_TREE); }
interface_body
+ { ; }
| INTERFACE_TK identifier extends_interfaces
{ create_interface (0, $2, $3); }
interface_body
+ { ; }
| modifiers INTERFACE_TK identifier extends_interfaces
{ create_interface ($1, $3, $4); }
interface_body
+ { ; }
| INTERFACE_TK identifier error
{yyerror ("'{' expected"); RECOVER;}
| modifiers INTERFACE_TK identifier error
@@ -1913,6 +1918,7 @@
exit_block ();
$$ = $1;
}
+;
catch_clause_parameter:
CATCH_TK OP_TK formal_parameter CP_TK
next prev parent reply other threads:[~2002-10-14 9:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-13 5:03 Kaveh R. Ghazi
2002-10-13 21:37 ` Matthias Klose
2002-10-14 6:46 ` Akim Demaille [this message]
2002-10-14 7:17 ` Akim Demaille
2002-10-15 3:06 ` Matthias Klose
-- strict thread matches above, loose matches on Subject: below --
2002-10-13 5:12 Kaveh R. Ghazi
2002-10-15 1:34 ` Mark Mitchell
2002-10-15 2:18 ` Zack Weinberg
2002-10-12 18:18 Matthias Klose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mv4r8etmm3t.fsf@nostromo.lrde.epita.fr \
--to=akim@epita.fr \
--cc=bug-bison@gnu.org \
--cc=debian-gcc@lists.debian.org.mark \
--cc=doko@cs.tu-berlin.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=ghazi@caip.rutgers.edu \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).