On Fri, 27 May 2016, Jan Hubicka wrote:
> Hi,
> this is version of patch which bootstrap®ress all languages at x86_64. OK?
The tree-pretty-print.c change is ok. I think the
> - if (stride)
> + if (stride && akind >= GFC_ARRAY_ALLOCATABLE)
should include a comment.
Richard.
> Honza
>
>
Hi,
this is version of patch which bootstrap®ress all languages at x86_64. OK?
Honza
* trans-types.c (gfc_array_range_type): Remove.
(gfc_init_types): Do not build gfc_array_range_type.
(gfc_get_array_type_bounds): Do not put unrealistic array bounds.
* trans-types
> As said I'd simply use NULL TYPE_MAX_VALUE, not drop TYPE_DOMAIN
> completely (yes, NULL TYPE_DOMAIN is equal to [0:] so we can as well
> print that - as you say, not sure what else breaks with that ;))
NULL TYPE_MAX_VALUE was used by my previous patch, because it used
gfc_array_range_type tha
On Tue, 24 May 2016, Jan Hubicka wrote:
> Hi,
> I tried the attached patch that gets rid of gfc_array_range_type because it
> seems pointless from middle-end POV. It however affects .original dumps in the
> following way:
> --- assumed_type_2.f90.003t.original2016-05-24 14:32:45.771503552 +020
Hi,
I tried the attached patch that gets rid of gfc_array_range_type because it
seems pointless from middle-end POV. It however affects .original dumps in the
following way:
--- assumed_type_2.f90.003t.original2016-05-24 14:32:45.771503552 +0200
+++ ../assumed_type_2.f90.003t.original 2016-05-2
> > 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]; c
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
>
> 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
> >
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,
> > >
> > - 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
>
On Mon, 23 May 2016, Jan Hubicka wrote:
> >
> > The assert below is unnecessary btw - it is ensured by IL checking.
> I removed the assert but had to add a check that sizes match. As sported by
> the
> testsuite, the declaration size doesn't need to match the size of object that
> we
> see.
> >
>
> The assert below is unnecessary btw - it is ensured by IL checking.
I removed the assert but had to add a check that sizes match. As sported by the
testsuite, the declaration size doesn't need to match the size of object that we
see.
>
> Rather than annotating an ARRAY_REF I'd have FEs annota
On Fri, 20 May 2016, Jan Hubicka wrote:
> Hi,
> this patch makes array_at_struct_end_p to not give up at MEM_REF as discussed
> on IRC few weeks back. This happens a lot for Fortran testcases.
> I am bootstrapping/regtesteing x86_64-linux and intend to commit it as
> obvoius.
>
> We sill miss a
Hi,
this patch makes array_at_struct_end_p to not give up at MEM_REF as discussed
on IRC few weeks back. This happens a lot for Fortran testcases.
I am bootstrapping/regtesteing x86_64-linux and intend to commit it as obvoius.
We sill miss a lot of upper bound for fortran code because we can not l
14 matches
Mail list logo
