On 4/29/21 11:32 AM, Jakub Jelinek wrote:
On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote:
The C front end (and perhaps others as well) creates internal
variables in a few places, such as in convert_lvalue_to_rvalue
like so:
/* Remove the qualifiers for the rest of the expressions and
create the VAL temp variable to hold the RHS. */
nonatomic_type = build_qualified_type (expr_type, TYPE_UNQUALIFIED);
tmp = create_tmp_var_raw (nonatomic_type);
tmp_addr = build_unary_op (loc, ADDR_EXPR, tmp, false);
TREE_ADDRESSABLE (tmp) = 1;
TREE_NO_WARNING (tmp) = 1;
Since the tmp decl "represents a compiler-generated entity" I'm
wondering if the last assignment in this functions (and others like
it) should instead (or in addition) be DECL_ARTIFICIAL (tmp) = 1
Certainly not. DECL_ARTIFICIAL is already set in create_tmp_var_raw,
so why would it try to set it again?
Why exactly is TREE_NO_WARNING set only some archeology will tell.
TREE_NO_WARNING was set in this function and in build_atomic_assign
in the fix for pr60195 which was about warnings for artificial
(atomic) variables.
TREE_NO_WARNING is also set in c_omp_clause_copy_ctor in the same
file, also for the result of create_tmp_var_raw. This was done in
your fix for pr65467 but that's not obviously related to warnings
and there's no comment explaining why it's done.
I (obviously) didn't realize that create_tmp_var_raw() set
DECL_ARTIFICIAL. Since it's already set, my other question is:
should DECL_ARTIFICIAL imply no-warning, or are there some
instances where it might makes sense to warn for artificial
variables? I can only think of cases where I didn't want to
warn for them in the middle end.
Martin
