On Thu, Aug 22, 2019 at 12:48 AM Jeff Law <l...@redhat.com> wrote: > > On 8/19/19 7:57 AM, Richard Biener wrote: > > > > > +static tree > > +objsize_from_type (tree object) > > +{ > > + if (TREE_CODE (object) != ADDR_EXPR) > > + return NULL_TREE; > > + > > + tree type = TREE_TYPE (object); > > + if (POINTER_TYPE_P (type)) > > > > that if looks suspicious... I'd say > > if (!POINTER_TYPE_P (type)) > > return NULL_TREE; > > > > is better > Sure. But we may not be able to use this anyway as you noted later, > depending on the type is not safe. > > > > > + type = TREE_TYPE (type); > > > > + if (TREE_CODE (type) == ARRAY_TYPE && !array_at_struct_end_p (object)) > > + { > > > > array_at_struct_end_p will never return true here since you pass it > > an ADDR_EXPR... you wanted to pass TREE_OPERAND (object, 0) here? > I think you're right. Given this was cribbed from the tail of another > function elsewhere, I suspect that other function has the same issue. > > I suspect ultimately we want to fix that other copy and drop > objsize_from_type. > > > > > > Also you seem to use this info to constrain optimization when you > > might remember that types of addresses do not carry such information... > > Thus it should be "trivially" possible to write a testcase that is > > miscompiled > > after your patch. I also don't see this really exercised in the > > testcases you add? > Arggh. You're absolutely correct. I must be blocking out that entire > discussion from last summer due to the trama :-) > > If the destination is the address of a _DECL node, can we use the size > of the _DECL?
Yes, but this should already happen for both invariant ones like &a.b.c and variant ones like &a.b[i].c in ao_ref_init_from_ptr_and_size. Richard. > > > > All of them reference a static array a ... > > > > + if (TREE_CODE (size) != INTEGER_CST) > > > > TREE_CODE (size) == SSA_NAME you want > Agreed. Will fix. > > jeff