Re: [tree-ssa] Merge status

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Wed, 17 Mar 2004, Ian Lance Taylor wrote:

> Yes, this is why I think it would be wise to have an unconditional
> warning for lvalue casts for two or three releases before actually
> removing the code.  It gives people a reasonable chance to fix their
> code, while letting their users simply ignore the warnings.

But why two or three releases?  The de facto FSF release cycle is a little
under one year (the theory is six months, but a year is nearer reality).  
If they only care for FSF releases, they have a year to fix the problems.  
That the problems show up as problems now, before 3.4 has even been
released, is an inevitable part of the curse of early adopters: if you use 
the code first, you get to fix the problems first.

Distributors may of course choose to maintain a deprecated feature for
longer, with a deprecation cycle based on their releases rather than FSF
releases; there are perfectly good reasons to do that (and one clear
disadvantage - if in a widely distributed compiler rather than one for a
particular client needing the feature - that it confuses users about what
GCC version x.y does or does not support).  The FSF release cycle must
however be the main [0] relevant cycle for deprecations in FSF GCC, and
given the limited volunteer resources for maintaining FSF GCC, improving
the maintainability of the code by quickly removing ugly code to support
dubious features seemed better than preserving such ugly code and
presumably trying to address regression bugs in extended lvalues caused by
corrections to the handling of standard code.

-fstrict-aliasing should be taken as an example of what to avoid in
deprecations.  Made available in EGCS 1.1 but off by default, so users
could experiment and fix their code, on by default in 2.95, disabled in
2.95.2 so users could fix their code (again), with an intention to provide
a warning later to tell users about broken code, reenabled in 3.0 without
such a warning and the warning added in 3.3 (and showing up much broken
code still about).  It's far from clear that making things more drawn out
will cause more code to be fixed until it unambiguously breaks (many
people do not use -Wall -Werror, nor thorough testsuites, which are also
difficult to implement for many sorts of code).

[0] Of course FSF development should and does take cognisance of what
distributors as well as direct users of FSF releases want, but a single
cycle can't be perfect for everyone and the FSF release cycle should be
some appropriate compromise accounting for the various needs, so is still
what's relevant for deprecations in FSF GCC.

-- 
Joseph S. Myers
jsm@polyomino.org.uk