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 jos...@codesourcery.com
