This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [fortran] Re: Make array_at_struct_end_p to grok MEM_REFs


On Tue, 24 May 2016, Jan Hubicka wrote:

> > > -  if (stride)
> > > +  if (stride && akind >= GFC_ARRAY_ALLOCATABLE)
> > >      rtype = build_range_type (gfc_array_index_type, gfc_index_zero_node,
> > >                               int_const_binop (MINUS_EXPR, stride,
> > >                                                build_int_cst (TREE_TYPE (stride), 1)));
> > > 
> > > It does not seem to make sense to build range types for arrays where the
> > > permitted value range is often above the upper bound.
> > 
> > Well, the ME explicitely allows domains with NULL TYPE_MAX_VALUE for this.
> > In the above case TYPE_MIN_VALUE is zero so you can omit the domain but
> > I believe that usually the FE communicates a lower bound of one to the ME.
> 
> I will give it a try to pass NULL here. Makes sense to me.  It seems the FE always 
> compensates by hand and all arrays in array descriptor starts by 0.
> > >    if (DECL_P (ref)
> > > +      /* Be sure the size of MEM_REF target match.  For example:
> > > +
> > > +	   char buf[10];
> > > +	   struct foo *str = (struct foo *)&buf;
> > > +
> > > +	   str->trailin_array[2] = 1;
> > > +
> > > +	 is valid because BUF allocate enough space.  */
> > > +
> > > +      && (!size || operand_equal_p (DECL_SIZE (ref), size, 0))
> > 
> > But it's still an array at struct end.  So I don't see how you
> > can validly claim it is not.
> 
> It is because the predicate is a bit misnamed. It really check whether 
> array is possibly trailing array, i.e. we can not rely on the fact that 
> all accesses are within the specified domain.

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 ...

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]