public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@rabi.columbia.edu>
To: egcs@egcs.cygnus.com
Cc: mark@codesourcery.com
Subject: Issues with g++.pt/decl2.C
Date: Tue, 27 Apr 1999 13:31:00 -0000	[thread overview]
Message-ID: <199904272030.QAA14852@blastula.phys.columbia.edu> (raw)

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

WARNING: multiple messages have this Message-ID
From: Zack Weinberg <zack@rabi.columbia.edu>
To: egcs@egcs.cygnus.com
Cc: mark@codesourcery.com
Subject: Issues with g++.pt/decl2.C
Date: Fri, 30 Apr 1999 23:15:00 -0000	[thread overview]
Message-ID: <199904272030.QAA14852@blastula.phys.columbia.edu> (raw)
Message-ID: <19990430231500.kE8HypvYxiJ4_vgZ-j0PpWu0T_2z9oDHh5jotoNe_Ok@z> (raw)

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

             reply	other threads:[~1999-04-27 13:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-27 13:31 Zack Weinberg [this message]
1999-04-27 13:44 ` Mark Mitchell
1999-04-27 19:51   ` Zack Weinberg
1999-04-27 21:28     ` Mark Mitchell
1999-04-28  6:39       ` Zack Weinberg
1999-04-30 23:15         ` Zack Weinberg
1999-04-30 23:15       ` Mark Mitchell
1999-04-30 23:15     ` Zack Weinberg
1999-04-30 23:15   ` Mark Mitchell
1999-04-30 23:15 ` Zack Weinberg

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=199904272030.QAA14852@blastula.phys.columbia.edu \
    --to=zack@rabi.columbia.edu \
    --cc=egcs@egcs.cygnus.com \
    --cc=mark@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).