https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
--- Comment #2 from Romain Geissler <romain.geissler at amadeus dot com> ---
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 <bb 4>; [94.29%]
else
goto <bb 5>; [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
