This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix c++ gc problems following t_r_o_c
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: geoffk at geoffk dot org, ghazi at caip dot rutgers dot edu
- Cc: gcc-patches at gcc dot gnu dot org, rth at redhat dot com
- Date: Sun, 7 Sep 2003 02:48:52 -0400
- Subject: Re: fix c++ gc problems following t_r_o_c
First, I have no opinion on Kaveh's specific patch.
It's important to me that I know how to report a bug so that gcc
people can reproduce it. I was suprised to learn that just specifying
my gcc "configure" line and the command line are not enough.
I also have to compile with "-v" and include the "GCC heuristics" line.
The gcc doco is the best I have ever seen on reporting bugs, but it
needs a bit of enhancement here.
In the future if I suspect that a bug is a gc bug, I can provide a
stack trace with ggc_collect right away.
I think we need more diversity of memory size in testing. People can
simulate low memory machines by setting "ulimit -d ...". I think it
would be helpful if some of the volunteer gcc testers and the
developers did this. And it helps with both the test suite and in
building the g++ libraries.
I don't even run the gcc test suite, I just happen to build gcc on
a puny 128 megabye machine a lot, so I exercise the c++ library
builder.
I think the real issue is the non-local programming paradigm where
function "A" expects no collections, and then "A" calls "B" calls "C"
calls "D" calls collect, and then bang. I have no ideas how to
handle this robustly.
Just my late night two cents, ignore me if this is trivial or wrong.
Michael C