This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Merge status
On Wed, 17 Mar 2004, Ian Lance Taylor wrote:
> We should keep that warning in there until we can reasonably expect
> that users have had a chance to see it on their code. Only then
> should we disable the feature entirely.
> Yes, this is harder on the gcc developers. But we should run some
> things for the convenience of the gcc users.
That's an ideal given infinite resources. Bug reports are in practice
closed based on being fixed in mainline which may not see a release for
over a year. Only the 3.3 and 3.4 branches have someone supporting them
in FSF GCC at all. There is no limit to how long a user may keep using an
old version that works for them; users have the chance to test a new
compiler without using it in production (keeping code compatible with
both) if they want, or they can choose never to upgrade, or to take a
bigger effort upgrading multiple releases at once. If a feature is ever
to be removed, users who upgrade at some point need to take the effort to
stop using that feature; the total effort doesn't depend on the length of
the deprecation period. Hitherto a single release period has been used on
the principle (I suppose) of getting it over and done with quickly rather
than dragging out the deprecation and delaying the benefits from removing
the feature. This feels to me almost like a case where the only
reasonable figures (for number of releases with deprecation) are 0, 1 and
infinity, and we've generally used 1.
If someone is following a careful process to qualify their code as working
with a new compiler, I'm not sure how much of an advantage it is for
something to yield a deprecation warning rather than a hard error, since
probably every new diagnostic needs dealing with.
Joseph S. Myers