Mark Mitchell wrote: > I'm all for more testing -- but I have a standard rant about it being > easier to run tests than to fix problems. We actually have a wealth > of known regressions -- some pretty serious -- in Bugzilla, and > plenty more known bugs. Most come from real problems reported by > real users on real code. So, it's not like we're running out of bugs > to fix.
That's true, but several factors frustrate people who want to fix bugs. Consider, as an example, the bug/non-bug at http://gcc.gnu.org/PR323, which was a matter of recent discussion on this list. Some rather respectable people (e.g., Vincent Lefèvre) consider this a bug, and have proposed solutions. Yet here's a quote from an earlier message by Giovanni Bajo. GB> You are mistaken, we think GCC isn't buggy about 323 because GB> the C/C++ standards do not tell us to do better than this. If GB> you have higher expectations about floating point and C/C++, GB> you should file a bugreport against the C/C++ standards. GB> Really, we can't make everybody happy. The best we can do is GB> to adhere the international well-known ISO/ANSI standards. The ISO Standard doesn't prevent GCC from being *better* than specified, does it? Are we somehow breaking ISO compliance by doing math right? Is it so wrong to try and fix a problem that frustrates many people and makes GCC look bad? With the attitude shown by Giovanni, there's really no point in submitting a patch, is there? Dozens of people have reported this problem, potential solutions exist, but any patch is going to be ignored because the bug isn't considered a bug by the Powers That Be. If I were to present a patch that implements the recomendations of the Numerical C Extensions Group, would it be accepted or rejected (on the subject alone; ignore for the moment potential technical bugs in the submitted code)? Documentation for the compiler itself is woefully inadequate for someone "new". GCC may be old-hat to folks who've worked on it for years, but it is very complex and foreign territory for most non-compiler experts. Working on GCC requires a much broader knowledge than working on other projects, and without some sort of tutorial or guidance, working on it quickly becomes frustrating. Here's an example: Building new targets and fixing some code generation bugs involve changing the machine definitions, which are written in a rather uncommon language. Frankly, I haven't figured out all the nuances yet, mostly because I don't have the luxury of studying it, and I can't find any clear and comprehensive documentation. Gentoo provides a mentoring system for developers. This is far better than GCC's "fix it yourself and send us the code" policy. There is no gentle way to become involved in GCC; it's a sink-or-swim, trial by fire environment. If I could get a half-dozen quick questions answered, and I could submit a couple of patches that are lying about on my hard drive. For that matter, Gentoo also has some very excellent IRC channels that provide a lot of help, and usually *friendly* help at that. The GCC mailing lists are useful, but there's nowhere to go and have a quick chat about "this is confusing the heck out of me" or "how do I approach this problem." I have submitted patches; I have tried to help with various aspects of GCC. I make no claim to having accomplished anything great, but I have tried, and watched patches die of bit rot while being told that certain bugs shouldn't be fixed. Everything in life is a matter of give and take. People report bugs; you want someone to fix the bugs -- perhaps GCC should be more welcoming and helpful. ..Scott
