I would like to contribute

I would like to contribute

[Regan Russell]

Hi, I would like to contribute to gcc.
I would like you to suggest a small project
otherwise, I will look for the simplest
problem in the bug list and investigate it.

Regan Russell BSc (Comp Sci)
www.users.bigpond.net.au/rrussell
regan_russell@hotmail.com
rrussell@c2.telstra-mm.net.au

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: I would like to contribute

[Martin v. Loewis]

> Hi, I would like to contribute to gcc.  I would like you to suggest
> a small project otherwise, I will look for the simplest problem in
> the bug list and investigate it.

You did not indicate what area you'd like to work on (some front-end,
some back-end, portability, etc). Here are a few things that could use
your attention:

1. Performance. People are observing a loss of efficiency both of the
   compiler itself, and of the generated code, in gcc 2.96 compared to
   2.95. Find out why that is, and propose corrections. The decreased
   code quality was observed primarily for C++, so you'd need to work
   on the C++ front-end here.

2. C99. There is a list at gcc.gnu.org/c99status.html telling what
   features are still missing. Pick one that sounds easy, and
   implement it.

3. Bug fixing. There are three sources for bugs; I'm not sure which
   one you were referring to:
   a) the expected failures in the test suite. In the g++.old-deja
      collection, look for files containing XFAIL
   b) the ever-growing GNATS list of problem reports. If you need to
      change the status of one of these (e.g. because you've found that
      one of the open reports does not report a bug), please let me know.
   c) the bug list on the bug reporting page. These are probably all 
      difficult to fix, that's why we put them there.

Regards,
Martin

Re: I would like to contribute

[Russell Browne]

Regan Russell wrote:
	
> Hi, I would like to contribute to gcc.
> I would like you to suggest a small project
> otherwise, I will look for the simplest
> problem in the bug list and investigate it.
	
Here is a suggestion I have contemplated making for several years.

When a C++ destructor is called, the destructor sets the vtable for
the object under destruction to the vtable for the destructor's class,
so that any virtual function calls go to that class's function rather
than that for a subclass that has now been destroyed.

This can be useful information when debugging if one is using a debugger
such as GDB or UPS that shows the vtable symbolically; if the vtable
shows that the class for an object is the base class of what it
ought to be the most likely cause is that you are looking at an object
that has been destroyed.  But this debugging trick does not work if the
object you are looking at is already supposed to be of either the base class
or a subclass.

Now my suggestion:  When compiled with debugging and without optimization,
the final step in a destructor for a base class, or for a class whose base
class does not have virtual functions, should be to set the vtable to a
distinctive value.  Possible values might be 0, 0xdeadbeaf, or to a symbol
that demangles to something like "destoyed object vtable".  If the last
approach, which I like best, is taken, implement such a vtable with the
first 100 or so entries going to a function that prints a message to
stderr and aborts.

Russ Browne
Applied MicroSystems Corp.