TREE_NO_WARNING and internal variables

TREE_NO_WARNING and internal variables

[Martin Sebor]

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
(and perhaps whether artificial variables should be treated as if
they had the NO_WARNING bit set; I think this might already be
done somewhere).

I replaced some of these TREE_NO_WARNING macros with DECL_ARTIFICIAL
to see what the effect might be on the tests and in the subset I ran
I saw only a couple of failures due to unexpected warnings that would
be avoided by treating artificial variables as if they also had
the no-warning bit set.

Thanks
Martin

PS The specific failure was gcc.dg/pr60195.c.

Re: TREE_NO_WARNING and internal variables

[Jakub Jelinek]

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.

	Jakub

Re: TREE_NO_WARNING and internal variables

[Martin Sebor]

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

Re: 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