This is the mail archive of the 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: [tree-ssa] Merge status

"Joseph S. Myers" <> writes:

> 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.

They have a year to fix the problem, provided they upgrade to each new
FSF release as it becomes available.  That is not reality.  Most users
freeze on a particular compiler release for several years.  That is
certainly what I did when working outside of the compiler business and
the free software world.  If you don't do that, you waste time
adjusting to the changes introduced by the new compiler.  It's much
easier to work with known bugs and deficiencies, backporting patches
when absolutely required, than it is to deal with the unknown of an
entire new release.

The FSF deprecation schedule makes no sense for people like that, and
I think that is a lot of people.  There are certainly plenty of people
still using 2.95.2 today, to judge by the regular issues arising as
they try to upgrade to newer releases.

> -fstrict-aliasing should be taken as an example of what to avoid in
> deprecations.

Yes, agreed.  That was also a harder problem to tackle for various

This one is, I believe, relatively easy to tackle.  I'm proposing an
unconditional warning, not enabled by -W or -Wall (but disabled by -w)
about using the extension syntax.  The extension should be easy to
identify--I haven't looked at the code, but since it is syntactic
sugar it must surely be there in the parser somewhere.  In fact, I see
that the 3.4 branch does have the warning.

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.

In my opinion.


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