This is the mail archive of the gcc-patches@gcc.gnu.org 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: PATCH RFC: Proposed patch for PR c++/7874


Ian Lance Taylor <ian@airs.com> wrote:

> I've brought up this type of issue before, and I know that I tend to
> be in the minority, but I am honestly trying to reflect the needs of
> the users of gcc here.  The needs of the users are not always the same
> as the needs of the developers, and I am biased in favor of the users.


I do think it's useful to help our users. I just don't feel the need for
such a thing. If an user is satisfied with GCC version X, and GCC version
X+1 does not work for him because of a bug in his code, then he can either
decide to fix the bug and upgrade immediately to X+1, or defer the bugfix to
a better moment and stay with versions X.

Sometimes I upgrade a library I use from version X to version X+1, and I
find out that version X+1 is not source compatible anymore, or they changed
something so that it does not work for me out-of-the-box. Then I have to
decide whether I want to tackle the issue immediatly so that I can upgrade
to version X+1 and takes advantage of other improvements, or stay with the
current version of the library, which already works for me. I don't expect
version X+1 of the library to be source compatible as it's a new version,
nor I expect them to provide a compatibility layer so that I can still use
X+1 version in "X" mode to ease the transition.

It's a balance each user has to take on his own.


> I do think it would be quite reasonable to group this under
> -fpermissive, so that we don't have to introduce a new option.

I believe this is a *worse* solution, actually. If an user starts
using -fpermissive because he does not want to fix a specific bug in his
codebase at upgrade time, then other bugs could easily slip in the
codebase: -fpermissive in fact makes the compiler accept even more broken
code, so new additions to the source code could contain more invalid code.
Later, he tries to get rid of -fpermissive, he will find out he might have
*more* bugs to fix, than only those for which he originally added the
option.

For instance, it would not be a good compromise for me. I would rather stay
with the current version with GCC, or upgrade and fix my bugs. Upgrading and
disabling strict checks also for other parts of the language for which my
code was already complaint doesn't really sound like a deal.

Thus, if we have to go this way, I'd rather have a different option for each
accepts-invalid bug fixed. We can batch-add those in the release branch
*only* (and use a meta-bug to remember to do this before the release), so
that those options will not be present anymore in the next GCC version.
We'll be thus giving user one full release cycle to have their bugs smashed.
-- 
Giovanni Bajo


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