This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Issues with g++.pt/decl2.C



g++.pt/decl2.C currently gets a spurious failure.  The error we're
looking for is "parse error at end of input".  g++ generates that
error with a line number one greater than the last complete line
scanned, i.e. if there were seven lines, you get "decl2.C:8: parse
error at EOF".  There's no way to tell old-deja that, so someone
hacked around the problem by removing the final newline from the file.
Unfortunately, the preprocessor always puts it back.

I tried to adjust the file so that it would get a parse error on line
7 instead of 8.  Unfortunately, the obvious change makes cc1plus segfault.

For reference, here's the current file:

---
// Build don't link:

// Simplified from testcase by Christophe Boyanique <boyan@imac.u-paris2.fr>

template <class T> struct foo { foo(); };
template<class T> foo<T>::foo() {}
T // ERROR - parse err at EOF
---

If I change it to

---
// Build don't link:

// Simplified from testcase by Christophe Boyanique <boyan@imac.u-paris2.fr>

template <class T> struct foo { foo(); };
template<class T> foo<T>::foo() {}
T; // ERROR - ICE - note added semicolon
---

then I get this:

(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x8178372 in split_specs_attrs (specs_attrs=0x82a3ad0, declspecs=0xbffff2a0, 
    prefix_attributes=0xbffff2a4) at ../../../egcs/gcc/c-common.c:1005
1005                a = TREE_CHAIN (a);
(gdb) bt
#0  0x8178372 in split_specs_attrs (specs_attrs=0x82a3ad0, 
    declspecs=0xbffff2a0, prefix_attributes=0xbffff2a4)
    at ../../../egcs/gcc/c-common.c:1005
#1  0x81bac2a in yyparse () at parse.y:614
#2  0x804b3a1 in compile_file (name=0x180 <Address 0x180 out of bounds>)
    at ../../../egcs/gcc/toplev.c:3244
#3  0x804e65b in main (argc=2, argv=0xbffffb64)
    at ../../../egcs/gcc/toplev.c:5416
(gdb) p a
$1 = (union tree_node *) 0x0
(gdb) l
1000                  TREE_CHAIN (a) = TREE_PURPOSE (t);
1001                  a = TREE_PURPOSE (t);
1002                }
1003              /* More attrs can be linked here, move A to the end.  */
1004              while (TREE_CHAIN (a) != NULL_TREE)
1005                a = TREE_CHAIN (a);
1006            }
1007        }
1008    
1009      /* Terminate the lists.  */

What appears to have happened is that TREE_PURPOSE (t) is NULL_TREE,
so a was null before entering the while loop, and we crash trying to
calculate TREE_CHAIN (a).

(gdb) p t
$4 = (union tree_node *) 0x82a3ad0
(gdb) pt
 <tree_list 0x82a3ad0 allocated from temp_decl_obstack
   >
(gdb) p t->list
$6 = {common = "\000\000\000\000\000\000\000\000\003\000\000", purpose = 0x0, 
  value = 0x0}

specs_attrs is equal to t, so yyparse() is passing bogus
arguments. 

(gdb) up
#1  0x81bac2a in yyparse () at parse.y:614
614                       split_specs_attrs ($1.t, &t, &attrs);
(gdb) l
609                     { pedwarn ("empty declaration"); }
610             | explicit_instantiation ';'
611             | typed_declspecs ';'
612                     {
613                       tree t, attrs;
614                       split_specs_attrs ($1.t, &t, &attrs);
615                       shadow_tag (t);
616                       note_list_got_semicolon ($1.t);
617                     }
618             | error ';'
(gdb) p yyvsp[-1].ftype.t
$10 = (union tree_node *) 0x82a3ad0
(gdb) pt
 <tree_list 0x82a3ad0 allocated from temp_decl_obstack
   >

This is as far as I can hunt this one.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]