Re: Beyond GCC 3.0: Summing Up

[dewar at gnat dot com]

>  A real-life example: the reload patch I did just before 3.0 which deleted
>  all USEs generated during reload.  It seemed obvious enough, but the mips
>  backend does horrible things with its reload_outdi pattern, emitting USEs
>  of dead (clobbered) registers.  Did the people working on mips investigate
>  why their backend suddenly broke?  Did they attempt to fix the problem
>  after I analyzed it (some time after the patch was reverted)?  No on both
>  counts.  We now have an unfixed bug with bogus USEs being left around, and
>  totally broken code in the mips backend, and no one is doing anything about
>  it.

It is easy enough to understand this position from a technical point of view,
but still, the result of the patch was to break the MIPS backend, and unless
there is a path to getting this fixed, the patch leaves an unacceptable
situation. Yes, of course someone should fix the MIPS backend, but until
someone does, you really cannot simply take the position -- too bad, gcc
no longer works on one current significant target, but it's not my fault,
and it will stay broken until someone else fixes it.

Breaking the compiler as a pressure tactic from one technical group to another
can sometimes work, but we have to make sure that users of the technology
do not get too discombobulated in the process. If there are no users, then
gcc is not much use!

> If it becomes too hard to make changes
> to gcc, people will go elsewhere (as it was proven before).

Sure and that's a concern, you definitely want to try to avoid frustrating
developers, but you also have to be sure not to frustrate users. There's a
balance there, and leaving a major target broken for an extended period of
time does not constitute an appropriate balance.