On Tue, 24 May 2016, Jan Hubicka wrote:
> >
> > Ah, yes. Now I see.
> >
> > > The test I updated that looks for DECL simply assumes
> > > that declarations can not be accessed past their end.
> > > It would make more sense to use object size machinery here somehow.
> > > (i.e. even in fortran we have accesses to mallocated buffers of constant
> > > size).
> > > But this probably could be better handled at niter side where we can also
> > > deal with
> > > case of real trailing arrays of known size.
> >
> > But then I'm not sure that TYPE_SIZE (TREE_TYPE (ref)) == NULL is
> > handled correctly. I suppose you can hope for the array to be the
> > one forcing it NULL and thus its TYPE_DOMAIN max val being NULL ...
>
> Hmm, you are probably right. If we can have array with TYPE_DOMAIN != NULL
> and sane bounds, but with TYPE_SIZE == NULL, we probably need to punt on NULL
> TYPE_SIZE. I can add it just to be sure.
As a MEM_REF embeds a VIEW_CONVERT you can placement-new
struct { int a[5]; char b[]; };
ontop of char X[24]; and access MEM_REF[&x].a[3] (not at struct end)
and MEM_REF[&x].b[4] but _both_ accesses would have TYPE_SIZE NULL.
So I'm not sure TYPE_SIZE tells you anything here...
Richard.
> I am testing
>
> Index: tree.c
> ===================================================================
> --- tree.c (revision 236557)
> +++ tree.c (working copy)
> @@ -13079,7 +13079,8 @@ array_at_struct_end_p (tree ref)
> tree size = NULL;
>
> if (TREE_CODE (ref) == MEM_REF
> - && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR)
> + && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR
> + && TYPE_SIZE (TREE_TYPE (ref)))
> {
> size = TYPE_SIZE (TREE_TYPE (ref));
> ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);
>
>
--
Richard Biener <rguent...@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
