https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71472
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
That is because we do this warning only when building each single || or && or |
or &.
And, we do this during parsing, where we don't know yet if the current
expression will appear in yet another identical operation or not.
If we extend the current warn_logical_operator so that for the range tests
it recurses over identical code suboperands, then either we'd have to limit the
walk to fixed number of operands we check and punt if you have say over 30 ||
expressions, or we'd risk exponential compile time.
Another possibility might be to remove this part of warn_logical_operator, and
perform it later, e.g. during c_fully_fold* and cp_fold, where we should have
the whole expressions already built and somehow signal to the recursive calls
that we want to handle it only on the outermost ||/&&/|/& (i.e. not perform it
if the parent code is the same as current code).
Then we could detect even e != ENUM_A || i != 42 || e != ENUM_B. Of course
for ||/&& we'd need to pay attention to side-effects in between,
e != ENUM_A || foo () || e != ENUM_B should not be warned about.
If we do that at that spot, we should basically try to virtually linearize the
trees combined with the same truth/logical binary operator, for all of them
perform the various checks warn_logical_operator does:
from_macro_expansion_at
TREE_NO_WARNING
CONSTANT_CLASS_P (fold_for_warn (...))
!(truth_value_p (TREE_CODE (...)) || INTEGRAL_TYPE_P (TREE_TYPE (...))
VECTOR_TYPE_P
make_range
build_range_check + integer_zerop (tem)
and stick the locations/make_range result/in*_p/low*/high* into a vector.
For operands with side-effects split the vector, then qsort each part without
side effects, so that we get records with the same make_range result next to
each other, and then perform the actual final checks and warnings.
