This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]