This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran] Re: Make array_at_struct_end_p to grok MEM_REFs
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, jvdelisle at gcc dot gnu dot org, tkoenig at gcc dot gnu dot org, pault at gcc dot gnu dot org
- Date: Tue, 24 May 2016 14:37:42 +0200 (CEST)
- Subject: Re: [fortran] Re: Make array_at_struct_end_p to grok MEM_REFs
- Authentication-results: sourceware.org; auth=none
- References: <20160520131048 dot GA55871 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1605201528050 dot 18037 at t29 dot fhfr dot qr> <20160523163236 dot GA60007 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1605241002370 dot 18037 at t29 dot fhfr dot qr> <20160524102702 dot GB63338 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1605241232520 dot 18037 at t29 dot fhfr dot qr> <20160524122259 dot GC60007 at kam dot mff dot cuni dot cz>
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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)