Issues with g++.pt/decl2.C

Issues with g++.pt/decl2.C

[Zack Weinberg]

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

Re: Issues with g++.pt/decl2.C

[Mark Mitchell]

Zack --

  Yes, this is a known bug.  In fact, Jason and I were just talking
about it at lunch!  The problem is that the lexer commits to T being a
template parameter too early in the game and it's really not.  There's
no really easy fix for this general problem, but I think we have a
long-term strategy for a solution.

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

Re: Issues with g++.pt/decl2.C

[Zack Weinberg]

On Tue, 27 Apr 1999 13:47:05 -0700, Mark Mitchell wrote:
>
>Zack --
>
>  Yes, this is a known bug.  In fact, Jason and I were just talking
>about it at lunch!  The problem is that the lexer commits to T being a
>template parameter too early in the game and it's really not.  There's
>no really easy fix for this general problem, but I think we have a
>long-term strategy for a solution.

Ok; in the mean time, we should fix the test case so it is testing the
problem, not a preprocessor quirk.  How about this:

// Build don't link:
// crash test - XFAIL *-*-*
template <class T> struct foo { foo(); };
template<class T> foo<T>::foo() {}
T; // ERROR - ICE - XFAIL *-*-*

zw

Re: Issues with g++.pt/decl2.C

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@rabi.columbia.edu> writes:

    Zack> Ok; in the mean time, we should fix the test case so it is
    Zack> testing the problem, not a preprocessor quirk.  How about
    Zack> this:

    Zack> // Build don't link: // crash test - XFAIL *-*-* template
    Zack> <class T> struct foo { foo(); }; template<class T>
    Zack> foo<T>::foo() {} T; // ERROR - ICE - XFAIL *-*-*

If that works, sure, it's fine.

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

Re: Issues with g++.pt/decl2.C

[Zack Weinberg]

On Tue, 27 Apr 1999 21:31:43 -0700, Mark Mitchell wrote:
>>>>>> "Zack" == Zack Weinberg <zack@rabi.columbia.edu> writes:
>
>    Zack> Ok; in the mean time, we should fix the test case so it is
>    Zack> testing the problem, not a preprocessor quirk.  How about
>    Zack> this:
>
>    Zack> // Build don't link: // crash test - XFAIL *-*-* template
>    Zack> <class T> struct foo { foo(); }; template<class T>
>    Zack> foo<T>::foo() {} T; // ERROR - ICE - XFAIL *-*-*
>
>If that works, sure, it's fine.

Yup, works.  I'll commit.

zw

Re: Issues with g++.pt/decl2.C

[Zack Weinberg]

On Tue, 27 Apr 1999 21:31:43 -0700, Mark Mitchell wrote:
>>>>>> "Zack" == Zack Weinberg <zack@rabi.columbia.edu> writes:
>
>    Zack> Ok; in the mean time, we should fix the test case so it is
>    Zack> testing the problem, not a preprocessor quirk.  How about
>    Zack> this:
>
>    Zack> // Build don't link: // crash test - XFAIL *-*-* template
>    Zack> <class T> struct foo { foo(); }; template<class T>
>    Zack> foo<T>::foo() {} T; // ERROR - ICE - XFAIL *-*-*
>
>If that works, sure, it's fine.

Yup, works.  I'll commit.

zw

Re: Issues with g++.pt/decl2.C

[Zack Weinberg]

On Tue, 27 Apr 1999 13:47:05 -0700, Mark Mitchell wrote:
>
>Zack --
>
>  Yes, this is a known bug.  In fact, Jason and I were just talking
>about it at lunch!  The problem is that the lexer commits to T being a
>template parameter too early in the game and it's really not.  There's
>no really easy fix for this general problem, but I think we have a
>long-term strategy for a solution.

Ok; in the mean time, we should fix the test case so it is testing the
problem, not a preprocessor quirk.  How about this:

// Build don't link:
// crash test - XFAIL *-*-*
template <class T> struct foo { foo(); };
template<class T> foo<T>::foo() {}
T; // ERROR - ICE - XFAIL *-*-*

zw

Re: Issues with g++.pt/decl2.C

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@rabi.columbia.edu> writes:

    Zack> Ok; in the mean time, we should fix the test case so it is
    Zack> testing the problem, not a preprocessor quirk.  How about
    Zack> this:

    Zack> // Build don't link: // crash test - XFAIL *-*-* template
    Zack> <class T> struct foo { foo(); }; template<class T>
    Zack> foo<T>::foo() {} T; // ERROR - ICE - XFAIL *-*-*

If that works, sure, it's fine.

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

Issues with g++.pt/decl2.C

[Zack Weinberg]

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

Re: Issues with g++.pt/decl2.C

[Mark Mitchell]

Zack --

  Yes, this is a known bug.  In fact, Jason and I were just talking
about it at lunch!  The problem is that the lexer commits to T being a
template parameter too early in the game and it's really not.  There's
no really easy fix for this general problem, but I think we have a
long-term strategy for a solution.

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