This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C/C++ PATCH] RFC: Implement -Wduplicated-cond (PR c/64249) (take
- From: Marek Polacek <polacek at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Wed, 23 Sep 2015 18:32:07 +0200
- Subject: Re: [C/C++ PATCH] RFC: Implement -Wduplicated-cond (PR c/64249) (take
- Authentication-results: sourceware.org; auth=none
- References: <20150918134434 dot GG27588 at redhat dot com> <55FC3FAD dot 4010501 at gmail dot com> <20150921170601 dot GK27588 at redhat dot com> <20150922122627 dot GN27588 at redhat dot com> <5601C92E dot 6000204 at gmail dot com>
On Tue, Sep 22, 2015 at 03:33:34PM -0600, Martin Sebor wrote:
> It's fine by me (for whatever it's worth).
Thanks. Let's wait if Jason/Joseph or anyone else wants to chime in.
> Btw., if you're unhappy about having to wipe out the whole chain
> after every side-effect it occurred to me that it might be possible
> to do better: instead of deleting the whole chain, only remove from
> it the elements that may be affected by the side-effect. This should
> make it possible to keep on the chain all conditions involving local
> variables whose address hasn't been taken, which I would expect to
> be most in most cases.
I'm not unhappy about deleting the chain ;). I'd rather not do that
because that might get somewhat hairy. First, I don't think we have
the capability to easily detect variables whose address hasn't been
taken, second, consider e.g.
if (j == 4) // ...
else if ((j++, --k, ++l)) // ...
else if (bar (j, &k)) // ...
we'd probably need some walk_tree, save the variables temporarily somewhere
etc.; that might slow and complicate things for a corner case. Or am I being
just too lazy? ;)
Thanks,
Marek