https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |mpolacek at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The C++ FE when parsing templates (processing_template_decl is true) produces a
lot of trees the middle-end doesn't like.
If they aren't type or value dependent, usually (but not always) the trees are
such that they can be handed over to the generic code even when parsing
templates.
The -Wduplicated-cond warning implemented in PR64249 seems to do:
condition = finish_if_stmt_cond (condition, statement);
if (warn_duplicated_cond)
warn_duplicated_cond_add_or_warn (token->location, condition,
&chain);
only in the parser regardless of processing_template_decl.
So, the options are either to make sure at least operand_equal_p can cope even
with those trees and apparently operand_equal_p already has such spots in it,
e.g.:
/* Similar, if either does not have a type (like a template id),
they aren't equal. */
if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
return false;
So, in this particular case, we'd punt if either field0 or field1 is not a
FIELD_DECL (this is in !OP_SAME (1) guarded code).
Another option is to make sure we don't call warn_duplicated_cond_add_or_warn
when processing_template_decl or say when value_dependent_expression_p or
similar, and instead call it during template instantiation in pt.cc after
finish_if_stmt_cond call there.
I think because operand_equal_p already has code to deal with the C++ special
trees and because it is such a low level API, changing it seems to be better.
