On Wed, 28 Jul 2021, Joseph Myers wrote:
> On Wed, 21 Jul 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > I wonder if instead when trying to wrap
> > C_MAYBE_CONST_EXPR into a VIEW_CONVERT_EXPR we shouldn't be
> > removing that C_MAYBE_CONST_EXPR and perhaps adding it around the
> > VIEW_CONVERT_EXPR. E.g. various routines in c/c-typeck.c like
> > build_unary_op remember int_operands, remove_c_maybe_const_expr
> > and at the end note_integer_operands.
> >
> > If Joseph thinks it is ok to have C_MAYBE_CONST_EXPR inside of
> > VCE, then the patch looks good to me.
>
> There are specific cases when a C_MAYBE_CONST_EXPR mustn't appear inside
> another expression: any case where the inner expression is required to be
> fully folded (this implies nested C_MAYBE_CONST_EXPR aren't allowed) and
> any case where the expression might appear (possibly unevaluated) in an
> integer constant expression (any C_MAYBE_CONST_EXPR noting that needs to
> be at top level).
>
> If the expressions involved here can never appear in an integer constant
> expression and do not need to be fully folded, I think it's OK to have
> C_MAYBE_CONST_EXPR inside VIEW_CONVERT_EXPR.
Since the expression in question involves GCC extensions to the C language
(vector types), it's not clear if they can be part of an integer constant
expression. The case is sth like
typedef long V __attribute__((vector_size(16)));
const long x = ((V)(V){1+1, 2+2})[2-1];
which we reject. In particular c_fully_fold_internal is fed
VIEW_CONVERT_EXPR<long int[2]>(VIEW_CONVERT_EXPR<vector(2) long int>(<<<
Unknown tree: compound_literal_expr
static V __compound_literal.0 = { 2, 4 }; >>>))[3]
in this case (no C_MAYBE_CONST_EXPR here), but we are not even turning
the COMPOUND_LITERAL_EXPR into a VECTOR_CST.
So I conclude that indeed the expressions involved here can never
appear in an integer constant expression.
Pushed to trunk.
Richard.
