On Thu, Apr 29, 2021 at 11:54:27AM -0600, Martin Sebor via Gcc wrote:
> 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.
It is intentional there.
> 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
DECL_ARTIFICIAL and TREE_NO_WARNING are independent things.
There can be cases where artificial vars are created on behalf of user
variables (e.g. for SRA etc.) where warnings might be appropriate.
Jakub
