This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/81928] if(!this) optimization leads to possible errors without warnings
- From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 23 Aug 2017 18:42:19 +0000
- Subject: [Bug c++/81928] if(!this) optimization leads to possible errors without warnings
- Auto-submitted: auto-generated
- References: <bug-81928-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #7 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Matthieu Brucher from comment #6)
> I never said that the test alone should be banned. Please read the original
> message first.
I had done so before I replied. And it seems that I'm not the only one who has
problems understanding your request.
> I said that if(!this) in the context of a method gives "unexpected" behavior
> (according to the standard and the difference in behavior of GCC between
> debug and optimized mode) and thus should give an error or at least a
> warning, and this is easy to catch.
I don't understand this. Please provide an example.
> At least make it a warning, like clang does when it detects that a path is
> always true or false, some kind of way for the user to _know_ that they
> messed up.
I already suggested the same thing: The only reason to request a warning in
this case is because the test result has only one outcome. But this is
absolutely unrelated to undefined behaviour unless you clarify what precisely
your mean.
> And yes, there is something fundamentally wrong with comparing this to
> nullptr according to the C++ standard and the contract GCC has in its
> optimizer.
You claim this repeatedly but I'm missing a proof for the "fundamentally wrong"
part. Except if you consider tautologies as "fundamentally wrong".
> Or give a reason why it is valid and where the standard says it
> supercedes the undefined behavior and the thread discussion on why GCC added
> the optimization constraint.
> And in that case, you should probably remove the optimization as well to be
> consistent.
This part is unclear without a specific example that you are talking about, see
above.