[smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[J.H.M. Dassen]

This problem was reported as a bug through the Debian bugtracking system
( http://www.debian.org/Bugs/ ); please Cc: 35477@bugs.debian.org on replies.

The problem is still reproducable with
gcc version egcs-2.93.13 19990321 (gcc2 ss-980929 experimental)
on a i586 Debian GNU/Linux "potato" system.

Greetings,
Ray
-- 
POPULATION EXPLOSION  Unique in human experience, an event which happened 
yesterday but which everyone swears won't happen until tomorrow.  
- The Hipcrime Vocab by Chad C. Mulligan 
>From pasquini@cs.purdue.edu Fri Apr 30 23:15:00 1999
From: Reuben Pasquini <pasquini@cs.purdue.edu>
To: egcs-bugs@cygnus.com
Subject: bug in egcs-g++-1.0.2-12
Date: Fri, 30 Apr 1999 23:15:00 -0000
Message-id: <3717A7F8.BE8C87D9@cs.purdue.edu>
X-SW-Source: 1999-04n/msg00464.html
Content-length: 4039

Hello,

I've come across a bug in egcs-g++-1.0.2-12 on my
RedHat 5.1 Linux system.  The problem results when
I try to instantiate an object of a class that
overides the new operator and is a subtype of two classes 
(multiple inheritance) that also both overide new.


I get the following error:

pasquini@joanne 9 tests/PCS/bin % make LP_thread.o
g++ -g -gstabs+ `guile-config compile` -fPIC -D_REENTRANT  
-I/home/pasquini/research/parasol/kernel/src
-I/home/pasquini/research/parasol/kernel/src/base
-I/home/pasquini/research/parasol/kernel/src/calendar
-I/home/pasquini/research/parasol/kernel/src/communication
-I/home/pasquini/research/parasol/kernel/src/driver
-I/home/pasquini/research/parasol/kernel/src/messages
-I/home/pasquini/research/parasol/kernel/src/runtime_stats
-I/home/pasquini/research/parasol/kernel/src/state
-I/home/pasquini/research/parasol/kernel/src/threads
-I/home/pasquini/research/parasol/kernel/src/virtual_time 
-I/home/pasquini/research/parasol/kernel/include
-I/home/pasquini/research/parasol/domains/common/include
-I/home/pasquini/research/parasol/domains/common/src -I../src
-I/usr/local/include/gc -I/usr/local/include  -c -o LP_thread.o
../src/LP_thread.cpp
../src/LP_thread.cpp: In method `void LP_thread::run()':
../src/LP_thread.cpp:62: Internal compiler error.
../src/LP_thread.cpp:62: Please submit a full bug report to
`egcs-bugs@cygnus.com'.


Line 62 is:
     op_mesh = new (MapNoGC) PCS_mesh ( i_mesh_dimension, op_rng );

I've attatched the code for LP_thread.cpp, PCS_mesh.hxx,
and PCS_mesh's two supertypes - Batch and State.
The Solaris CC compiler is able to handle this code,
so I assume it's correct.

Thanks for your work on egcs, and good luck.
Reuben

-- 
-------------------------------------------------------------------------
Reuben Pasquini                     pasquini@cs.purdue.edu
Department of Computer Science      www.cs.purdue.edu/people/pasquini
Purdue University                   Fax: 1-765-494-0739
West Lafayette, IN 47907-1398       Office: 765-494-0361
-------------------------------------------------------------------------
/**
 * LP_thread.cpp: LP_thread for the PCS simulation 
 *
 * @author Reuben Pasquini
 * @log 
 *      04/14/1999 - created from torus/LP_thread
 */

#include <iostream.h>
#include <fstream.h>
#include <stdlib.h>     // for getenv
#include <unistd.h>
#include <stdio.h>

#include "LP_thread.hxx"
#include "PCS_mesh.hxx"
#include "PCS_cell.hxx"
#include "Debug.hxx"
#include "Work_thread.hxx"
#include "Random.hxx"

extern "C" {
#include <libguile.h>
#include <guile/gh.h>
};

extern Kernel * gp_kernel;

/**
 * LP_thread::LP_thread (): constructor does nothing since the
 *       ParaSol kernel hasn't been initialized yet. 
 *       Initialization at the beginning of ::run ()
 *
 * @log  
 *     04/14/1999 - created
 */
LP_thread::LP_thread () {
  op_rng = 0;
  op_mesh = 0;
}


/**
 * LP_thread::run: this is the work routine which actually creates 
 *      the global objects and launches the initial threads
 *
 * @log 
 *     09/05/1997 - created
 */
void 
LP_thread::run () {
  {
    char  s_dirname[ 80 ];
    sprintf ( s_dirname, "/homes/pasquini/tmp/core%d", gp_kernel->ProcId () );
    chdir ( s_dirname );
  }

  int i_mesh_dimension = (int)( gh_scm2long(gh_eval_str ( "mesh_dimension" )) );
  assert ( i_mesh_dimension > 1 );
  gp_kernel->debug ( DEB_APP, 0.0 ) << "Allocating rng & mesh" << endl;
  op_rng = new (MapNoGC) Random ();
  op_mesh = new (MapNoGC) PCS_mesh ( i_mesh_dimension, op_rng );

  // Now let's create some threads that just make work
  for ( Iterator* p_iterator = op_mesh->iterator ();
	p_iterator->hasNext (); ) {
    PCS_cell* p_cell = (PCS_cell*)( p_iterator->next () );
    if ( p_cell->ProcId () == gp_kernel->ProcId () ) { // it's a local cell
      Thread* p_workmaster = new (GC) Work_thread ( op_rng, p_cell, op_mesh );
      p_workmaster->bootstrap ();
    }
  }
  hold_till_end ();
  gp_kernel->debug ( DEB_APP, gp_kernel->Time () ) 
  << "Master thread running for last time!" << endl;
}
>From vavasis@CS.Cornell.EDU Fri Apr 30 23:15:00 1999
From: Stephen Vavasis <vavasis@CS.Cornell.EDU>
To: egcs-bugs@egcs.cygnus.com
Subject: ostream with 0 constructor
Date: Fri, 30 Apr 1999 23:15:00 -0000
Message-id: <37212025.3C21@cs.cornell.edu>
X-SW-Source: 1999-04n/msg00671.html
Content-length: 758

The code below does not work in egcs-1.1.2 running under Sun Solaris
2.5.1.  It compiles OK (no arguments passed to g++ other than the source
file name), but when executed, it gives a segmentation fault.

I believe that an ostream constructed with an argument of 0 is supposed
to discard all its characters and do nothing.  This is how ostream works
in KCC 3.2f and VC++5.0. 

Assuming that the program below really does indicate an egcs bug (rather
than my incorrect understanding of ostream), can someone tell me the
workaround?  How do I create an ostream that discards all its output?

Thanks,
Steve Vavasis

#include <iostream>

using std::ostream;
using std::endl;

int main() {
  ostream nullstr(0);
  nullstr << "hello world" << endl;
  return 0;
}

Re: [smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[Mike Stump]

> Date: Thu, 8 Apr 1999 22:51:10 +0200
> From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> > Known bug, unlikely to be fixed soon.

> I wouldn't be that pessimistic about it.

Ok, then name a date when you think it will be available.  Then on
that date, email me and tell me if it was available in a released
compiler.  We can then see if your predictive capabilities are better.
My best guess is that not before Mar 2000 will he have the problem
fixed in a released compiler.  By fixed, I mean, no new bugs (related
to this feature), and complete functionality that is present with
non-thunk compilers.  To me, soon doesn't include code a year+ out.

Re: [smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[Martin v. Loewis]

> Known bug, unlikely to be fixed soon.

I wouldn't be that pessimistic about it.

http://egcs.cygnus.com/ml/egcs-patches/1999-04/msg00103.html

has a patch that fixes the problem (with a number of draw-backs, as
explained).

Regards,
Martin

Re: [smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[Mike Stump]

Known bug, unlikely to be fixed soon.  For more information see the
egcs archives.  This is the `you can't call virtual functions that
cross virtual derivation boundaries at ctor/dtor time because we don't
implement dymanic thunks' problem.

Re: [smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[Jeffrey A Law]

  In message < 199904082139.OAA18747@kankakee.wrs.com >you write:
  > > Date: Thu, 8 Apr 1999 22:51:10 +0200
  > > From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
  > 
  > > > Known bug, unlikely to be fixed soon.
  > 
  > > I wouldn't be that pessimistic about it.
  > 
  > Ok, then name a date when you think it will be available.
That's unreasonable and unfair.  It's a work in progress that seems to be
making significant progress.

Not to be mean, but at least he's working to resolve the problem.  You haven't.


jeff

Re: [smkelly@zombie.org: Bug#35477: gcc: egcs C++ class mishandling.]

[Jeffrey A Law]

  In message < 199904051821.LAA07990@kankakee.wrs.com >you write:
  > Known bug, unlikely to be fixed soon.  For more information see the
  > egcs archives.  This is the `you can't call virtual functions that
  > cross virtual derivation boundaries at ctor/dtor time because we don't
  > implement dymanic thunks' problem.
Actually, someone is working on the dynamic thunks problem.  I believe they
even posted a new snapshot of their work within the last few days.

Don't make it sound so bleak.

jeff