[C PATCH RFC] Drop qualifiers during lvalue conversion

[Joseph Myers]

On Sun, 15 Nov 2020, Uecker, Martin wrote:

> > I think it might be safest to avoid doing any conversion in the case where 
> > the value is still of array type at this point (C90 non-lvalue arrays).
> 
> I added a test for arrays, but I am not sure what effect it has.
> What would be C90 non-lvalue arrays?  Anything I can test?

In C90, a non-lvalue array (an array member of a non-lvalue structure or 
union, obtained by a function return / assignment / conditional expression 
/ comma expression of structure or union type) did not get converted to a 
pointer.  This meant there was nothing much useful that could be done with 
such arrays, because you couldn't access their values (technically I think 
you could pass them in variable arguments and retrieve them in the called 
function with va_arg, but that doesn't help because it just gives another 
non-lvalue copy of the value that you still can't do anything useful 
with).

The possible breakage I'm concerned about isn't something that can readily 
be tested for; it's that if you create an unqualified array type directly 
with build_qualified_type (not going through c_build_qualified_type), you 
may break the invariants regarding how arrays of qualified element types 
are represented internally in GCC, and so cause subtle problems in code 
relying on such invariants.  (Cf. the problem with inconsistency in that 
area that I fixed with 
<https://gcc.gnu.org/legacy-ml/gcc-patches/2005-01/msg02180.html> (commit 
46df282378908dff9219749cd4cd576c155b2971).)  Avoiding these conversions in 
the case of arrays, as this version of the patch does, seems the simplest 
way to avoid any such issues arising.

> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index 2566ec7f0af..f83b161b2e8 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -5518,6 +5518,18 @@ gimplify_modify_expr_rhs (tree *expr_p, tree *from_p, tree *to_p,
>  	    return GS_OK;
>  	  }
>  
> +	case NOP_EXPR:
> +	  /* Pull out compound literal expressions from a NOP_EXPR.
> +	     Those are created in the C FE to drop qualifiers during
> +	     lvalue conversion.  */
> +	  if (TREE_CODE (TREE_OPERAND (*from_p, 0)) == COMPOUND_LITERAL_EXPR)

A NOP_EXPR might sometimes be doing an actual conversion (say the compound 
literal is (int){ INT_MAX }, converted to short).  I think this should 
check tree_ssa_useless_type_conversion to make sure it's safe to remove 
the conversion.

-- 
Joseph S. Myers
joseph@codesourcery.com