> I understand removing it simplified GCC. That is good. Unfortunately by
> saving work for yourselves you made much more work for many other
> people. I see from Google that Andrew Morton simply used old compilers
> when faced with this problem before.

That's indeed unfortunate and has already been complained about several times.

> As recent releases have broken more and more code, I would like to
> understand what GCCs policy on source compatibility is. Sometimes the
> code was buggy, in this particular case GCC simply decided to pull an
> extension it has offered for years. Is it documented anywhere? Are there
> any more planned breakages? How do you make the cost:benefit judgement
> call? Are there any guidelines you follow?

Generally speaking, this occurs as follows: a patch happens to break an 
extension because GCC has (had?) so many extensions that it is nearly 
impossible to foresee all the side-effects a patch will have on them.  Then 
somebody notices the breakage and complains about it, and sometimes even 
writes a patch to undo the breakage (typically an Apple employee, because 
Apple is legitimately concerned about backwards compatibility).  Then the 
patch is knocked down by the language lawyers who are floating around 
because, see, if the extension was broken, it probably deserved it as it was 
under-specified and, consequently, cannot be anything else than an 
abomination.

Admittedly a bit caricatural, but not that much.

> Typically a warning was emitted for a release or two before but this
> achieves little: old unmaintained code, or code too large/fragile to fix
> up, will not be fixed anytime soon. In other cases people like me must
> spend our spare time doing boring mechanical work for no obvious reason,
> so it is usually left until it actually starts causing compiles to fail.
> This is quite depressing.

I agree, GCC should not be known for randomly breaking compatibility with 
itself, in addition to its other weaknesses.

> In cases where breaking sources lets you achieve greater performance or
> efficiency, please do make the change but offer a switch to disable it and
> let the old code still compile. This way we it seems everybody can be
> happy.

My impression is that this has nothing to do with performance and efficiency, 
unfortunately.

-- 
Eric Botcazou

Reply via email to