This is the mail archive of the gcc@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: Less radical proposal (was Re: Radical proposal: skip 3.4)



On Jan 10, 2004, at 5:09 PM, Nathanael Nerode wrote:


Phil Edwards wrote:
So, here's a suggestion: during stage 3, this rule should be more
vigourously ... eh, "enforced" isn't quite the word I want, but it's close.
For those two months, we really should be seeing more bugs fixed than
new code committed. Yah, I know fixing bugs isn't sexy, but getting our
collective ass whomped by commercial compilers is even less sexy. Yah, I
know nobody here wants to be the unpopular bully who vetos perfectly good
new dev work during those two months, but I think it'll still be needed.
I've been fixing bugs. But it takes me a lot longer than it takes me to implement structural improvements. :-/

Actually, what takes longer isn't *fixing* the bugs per se; it's tracking them down. I like doing that, but (for me) it's sloooow work.


One of the things i love about LLVM is bugpoint.
It can tell you what pass is causing a bug, etc, just by handing it a piece of code.
We *really* need something like it for GCC, but it will require being able to parse dump output so that we can pass it to passes separately.
It also requires a clean separation of passes, something that exists in tree-ssa, but i'm not so sure about the backend (at least, the few times i've tried to move passes around so that they are run in a different order, it ICE's in one way or another).



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