[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
kal.conley at dectris dot com changed:
What|Removed |Added
CC||kal.conley at dectris dot com
--- Comment #6 from kal.conley at dectris dot com ---
We are hitting this warning too with:
#include
#include
int main() {
std::vector inputs(2);
std::vector outputs{inputs.begin(), inputs.end()};
outputs.back() = 1;
return 0;
}
Regards,
Kal
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #5 from Martin Sebor --- Few middle-end warnings consider control flow -- most simply look at a single statement at a time and consider ranges of argument values (if any). Those that do consider control flow (e.g., -Wreturn-local-addr) only do so for PHI nodes that, for the most part, are the result of ?: expressions. We have work underway to improve the way GCC computes and exposes range information that we expect will help improve the accuracy in cases where there's more than a single range. I've also been thinking about changing some existing warnings to consider control flow to improve both their accuracy and efficacy, but this would only make a difference for PHI nodes. I haven't thought too much about using branch probabilities to decide whether to issue a maybe kind of a warning. Right now, a statement in the IL with a constant out-of-bounds argument triggers a definitive warning regardless of how likely the branch it's in is executed. It might be something to explore, though I would expect it to quickly turn most warnings in non-trivial code into the maybe kind. Using 'if (condition) __builtin_unreachable ();' shouldn't have an adverse effect on efficiency. Rather I'd expect it to improve codegen since it tells GCC that and any code that would otherwise be reachable after it can be eliminated. I would expect its effects to be comparable to __builtin_assume (condition).
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #4 from Romain Geissler --- Thanks Richard. Indeed, beyond the false positive described in this bug, our whole code that implement "relative pointer" is I think quite hacky and not very compiler friendly (around alignment, aliasing rule, pointer arithmetic). We should review and update it a lot. Actually a similar class exists in Boost.Interprocess under the name "offset_ptr", and they did write this in their header: https://github.com/boostorg/interprocess/blob/develop/include/boost/interprocess/offset_ptr.hpp //Note: using the address of a local variable to point to another address //is not standard conforming and this can be optimized-away by the compiler. //Non-inlining is a method to remain illegal but correct //Undef BOOST_INTERPROCESS_OFFSET_PTR_INLINE_XXX if your compiler can inline //this code without breaking the library any time they need to deal with pointer to offset conversion, or vice-versa. I happens that we also suffer from similar problems and had to put attribute "noinline" "randomly" in places to "fix" (actually workaround our poor understanding of how the compiler works) problems we are seeing with the behavior of this library when compiled with optimizations. We should obviously review greatly in depths what we are doing which seems wrong in many places. PS Martin: I am ok to leave unresolved, just I think the wording of the error should be somehow updated so that the fact that it's only a possibility for not a certainty, other of your warnings around string management do print the range of value that gcc found out is possible, and that helps in understanding and fixing/silencing the warnings.
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-03-26 Status|UNCONFIRMED |NEW
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #3 from Richard Biener --- You should be using (intptr_t)t - (intptr_t)this when computing the relative pointer, not sure if that makes a difference but pointer difference between pointers to different objects invokes undefined behavior.
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #2 from Romain Geissler --- Thanks for the explanation. However few observations: - Is it really expected that the wording of the warning seems to imply gcc knows for sure that there is an invalid access ? What is the warning meant to find ? Potential issues, or real issues gcc can prove will happen 100% of the time ? Here I see that you pasted: if (_24 != -9223372036854775808) goto ; [94.29%] else goto ; [5.71%] so gcc itself is able to see that the most likely case is that we go in basic block 4 rather than 5 which emits this warning. So either the wording of the warning shall be updated to reflect that "maybe" the code wrong, either if possible we should try to make a different when gcc is sure and when it is not (like -Wuninitialized vs -Wmaybe-uninitialized). - Second observations, how do you suggest we teach gcc that this is indeed a false positive and we want the warning to be silenced. You mentioned "if (d == kEmptyPointer) __builtin_unreachable;", does this statement result in effectively having a new basic block branching where one side terminates the program and the other runs the actual expected behavior of "setVal". In other words, will the condition in the "if" really be emitted by the codegen and evaluated at runtime, or do I have the guarantee it will not emit new branches and only teach the optimizer that some cases are impossible ? In the case the answer is that it will emit a real codegen branch potentially impacting runtime, do you think it's worth adding a __builtin_assume in gcc like clang has (not in gcc 10 obviously, but in gcc 11 during stage 1) ? Cheers, Romain
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
This type of warning is new GCC 10; it was added in the commit below. It works
as designed here. It sees the following IL (the memset calls don't do
anything). The MEM[] = 65; statement is what triggers it.
[local count: 1073741824]:
aDummyBuffer_4 = malloc (10);
it ={v} {CLOBBER};
if (aDummyBuffer_4 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619281]:
_24 = aDummyBuffer_4 -
it.d = _24;
itCopy ={v} {CLOBBER};
if (_24 != -9223372036854775808)
goto ; [94.29%]
else
goto ; [5.71%]
[local count: 708669601]:
_23 = aDummyBuffer_4 -
itCopy.d = _23;
*aDummyBuffer_4 = 65;
aDummySource_97 = malloc (10);
D.40357 ={v} {CLOBBER};
_17 = aDummyBuffer_4 -
D.40357.d = _17;
goto ; [100.00%]
[local count: 365072224]:
itCopy.d = -424242;
MEM[(char *) + -424242B] = 65; <<< warning here
aDummySource_105 = malloc (10);
D.40357 ={v} {CLOBBER};
D.40357.d = -424242;
...
[local count: 322122544]:
it.d = -9223372036854775808;
itCopy ={v} {CLOBBER};
goto ; [100.00%]
It doesn't matter (much) whether the initial address is or can be null (the
warning persists even with operator new that doesn't return null or when the
ctor never does set d to kEmptyPointer). The branch of the code that sets d
to -424242 isn't eliminated because the pointer subtraction in either ctor
could, as far as GCC can tell, result in the same value as kEmptyPointer.
Asserting that the subtraction doesn't result in such a value, for instance
like so:
if (d == kEmptyPointer) __builtin_unreachable ();
and also guaranteeing that the initial address isn't null (e.g., by using
operator new) eliminates the warning.
Short of teaching GCC that the magnitude of the difference between any two
pointers must be less than PTRDIFF_MAX I don't think there's anything that can
be done do improve things (either codegen, or avoid the warning in this case).
I'll leave this report unresolved in case someone feels otherwise.
commit b631bdb3c16e85f35d38e39b3d315c35e4a5747c
Author: Martin Sebor
Date: Thu Jul 25 00:29:17 2019 +
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source not folded
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source not folded
PR tree-optimization/86688 - missing -Wstringop-overflow using a non-string
local array in strnlen with excessive bound
