[PATCH] c/101512 - fix missing address-taking in c_common_mark_addressable_vec

Richard Biener rguenther@suse.de
Wed Jul 28 10:14:55 GMT 2021


On Wed, 21 Jul 2021, Jakub Jelinek wrote:

> On Wed, Jul 21, 2021 at 10:06:51AM +0200, Richard Biener wrote:
> > c_common_mark_addressable_vec fails to look through C_MAYBE_CONST_EXPR
> > in the case it isn't at the toplevel.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> > 
> > Thanks,
> > Richard.
> > 
> > 2021-07-21  Richard Biener  <rguenther@suse.de>
> > 
> > 	PR c/101512
> > gcc/c-family/
> > 	* c-common.c (c_common_mark_addressable_vec): Look through
> > 	C_MAYBE_CONST_EXPR even if not at the toplevel.
> > 
> > 	* gcc.dg/torture/pr101512.c: New testcase.
> 
> 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.

Joseph - any comments?  The above mentioned issue is pre-existent,
EXPR_INT_CONST_OPERANDS should be false on vector types though,
so eventually the C_MAYBE_CONST_EXPR is entirely pointless,
but it's unconditionally built in build_compound_literal but
C_MAYBE_CONST_EXPR_NON_CONST is set there.  The VIEW_CONVERT_EXPR
is built via convert(), the types have the same main variant,
just one is not named.  But nothing in convert() seems to care
about C_MAYBE_CONST_EXPR.

Thanks,
Richard.


More information about the Gcc-patches mailing list