TREE_NO_WARNING and internal variables

[Jakub Jelinek]

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