🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.g++.bug
Article #233

I think there is a bug in finish_file()

#233
From: Dave Daney
Date: Fri, 10 Apr 1992 17:04
124 lines
4810 bytes
Am I missing something?  Here is a file that I tried to compile with gcc 2.1
--------------------<cut here>-------------------------------
//
//
//  Why does this program cause cc1plus 2.1 to segmentation fault??
//
//

class testclass {
  int len;

public:
  int length() { return len; };
  
  testclass(int l) {len = l; };
};


testclass test = testclass(5);

int main(int argc, char *argv[])
{
  int j = test.length();

  return 0;
}

--------------------------------------<cut here>-------------------
I compile like this:


Reading specs from /usr/gnu/lib/gcc-lib/sparc/2.1/specs
gcc version 2.1
 /usr/gnu/lib/gcc-lib/sparc/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix bug.cc /usr/tmp/cca26668.i
GNU CPP version 2.1 (sparc)
 /usr/gnu/lib/gcc-lib/sparc/2.1/cc1plus /usr/tmp/cca26668.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca26668.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
gcc: Internal compiler error: program cc1plus got fatal signal 11


The same thing happens when compiled on Interactive 2.2.1 (Sys V/386 R3.2)

Here is a backtrace etc.

 (gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/lib/gcc-lib/i386-none-isc/2.1/cc1plus bug.i -dumpbase bug.cc -quiet -o bug.s -version
GNU C++ version 2.1 (80386, ATT syntax) compiled by GNU C version 2.1.

Program received signal 11, Segmentation fault
0x7542c in expand_call (exp=0x43de90, target=0x0, ignore=0, 
    modifier=EXPAND_SUM) at calls.c:764
(gdb) bt
#0  0x7542c in expand_call (exp=0x43de90, target=0x0, ignore=0, 
    modifier=EXPAND_SUM) at calls.c:764
#1  0x70b4b in expand_expr (exp=0x43de90, target=0x0, tmode=VOIDmode, 
    modifier=EXPAND_SUM) at expr.c:3425
#2  0x705d9 in expand_expr (exp=0x427690, target=0x43dee0, tmode=BLKmode, 
    modifier=EXPAND_NORMAL) at expr.c:3181
#3  0x6edb6 in store_expr (exp=0x427690, target=0x43dee0, suggest_reg=0)
    at expr.c:2088
#4  0x6ec08 in expand_assignment (to=0x43dcbc, from=0x427690, want_value=0, 
    suggest_reg=0) at expr.c:1998
#5  0x721c6 in expand_expr (exp=0x427690, target=0x0, tmode=VOIDmode, 
    modifier=EXPAND_NORMAL) at expr.c:4337
#6  0x6957c in expand_expr_stmt (exp=0x4276a4) at stmt.c:1195
#7  0x42b8c in expand_aggr_init_1 (binfo=0x433a30, true_exp=0x43dcbc, 
    exp=0x43dcbc, init=0x43deac, alias_this=0, flags=1) at cp-init.c:1343
#8  0x424c1 in expand_aggr_init (exp=0x43dcbc, init=0x43deac, alias_this=0)
    at cp-init.c:1055
#9  0x19bdb in finish_file () at cp-decl2.c:2228
#10 0x48e in yyparse (4405424) at cp-parse.c:422
#11 0x57ade in compile_file (name=0x7ffffe4d "bug.i") at toplev.c:1607
#12 0x59bfb in main (argc=8, argv=0x7ffffda8, envp=0x7ffffdcc) at toplev.c:3012
(gdb) print type



print type
$24 = (union tree_node *) 0x29e63710
(gdb) print p
$26 = (union tree_node *) 0x43de18
(gdb) ptc
TREE_LIST
 


this value for type is way outside of any reasonable address.
--------------------------------------------------------------------------
this is in calls.c around line 764

  /* I counts args in order (to be) pushed; ARGPOS counts in order written.  */
  for (p = actparms, argpos = 0; p; p = TREE_CHAIN (p), i += inc, argpos++)
    {
      tree type = TREE_TYPE (TREE_VALUE (p));

      args[i].tree_value = TREE_VALUE (p);

      /* Replace erroneous argument with constant zero.  */
=>    if (type == error_mark_node || TYPE_SIZE (type) == 0)
	args[i].tree_value = integer_zero_node, type = integer_type_node;

      /* Decide where to pass this arg.

	 args[i].reg is nonzero if all or part is passed in registers.

	 args[i].partial is nonzero if part but not all is passed in registers,
	 and the exact value says how many words are passed in registers.

	 args[i].pass_on_stack is nonzero if the argument must at least be
	 computed on the stack.  It may then be loaded back into registers
	 if args[i].reg is nonzero.

	 These decisions are driven by the FUNCTION_... macros and must agree
	 with those made by function.c.  */




************************************************************************
I hope I didn't do any thing stupid, but I never can tell with this stuff.

David Daney.
Technical Details
Message-ID: <199204110304.AA21383@mermaid.micro.umn.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!mermaid.micro.umn.edu!daney

Show Full Headers
Complete Article Headers
Newsgroups: gnu.g++.bug
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!mermaid.micro.umn.edu!daney
From: daney@mermaid.micro.umn.edu (Dave Daney)
Subject: I think there is a bug in finish_file()
Message-ID: <199204110304.AA21383@mermaid.micro.umn.edu>
Sender: gnulists@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 17:04:15 GMT
Approved: bug-g++@prep.ai.mit.edu
Lines: 126