On Fri, 16 Oct 2020, Richard Biener wrote:

> On Fri, 16 Oct 2020, Jan Hubicka wrote:
> 
> > Hi,
> > I am slowly getting finished with the fn spec changes on trunk and then
> > would like to proceed with modref.  Sadly  still get the assumed_type
> > failuere and in addition to that:
> > FAIL: gfortran.dg/finalize_25.f90   -O2  execution test
> > FAIL: gfortran.dg/finalize_25.f90   -O3 -fomit-frame-pointer -funroll-loops 
> > -fpeel-loops -ftracer -finline-functions  execution test
> > FAIL: gfortran.dg/finalize_25.f90   -O3 -g  execution test
> > FAIL: gfortran.dg/finalize_25.f90   -Os  execution test
> > WARNING: gfortran.dg/pdt_14.f03   -O2  execution test program timed out.
> > FAIL: gfortran.dg/pdt_14.f03   -O2  execution test
> > WARNING: gfortran.dg/pdt_14.f03   -O3 -fomit-frame-pointer -funroll-loops 
> > -fpeel-loops -ftracer -finline-functions  execution test
> > program timed out.
> > FAIL: gfortran.dg/pdt_14.f03   -O3 -fomit-frame-pointer -funroll-loops 
> > -fpeel-loops -ftracer -finline-functions  execution test
> > WARNING: gfortran.dg/pdt_14.f03   -O3 -g  execution test program timed out.
> > FAIL: gfortran.dg/pdt_14.f03   -O3 -g  execution test
> > WARNING: gfortran.dg/pdt_14.f03   -Os  execution test program timed out.
> > FAIL: gfortran.dg/pdt_14.f03   -Os  execution test
> > 
> > I wonder if there is any chance to get Fortran FE fixed here?
> 
> OK, I'll try doing a little surgery in the FE today, coming up with
> a little refactoring and a fix along your original one that allows
> for a better one by FE folks.

So I've sent a refactoring patch improving the tree building code.

But now trying to fix the actual issue with the idea to perform
accesses indirectly via a descriptor with dim[] type I see that
the coarray 'token' field is appended to descriptors conditional
on -fcoarray and that this field makes the dim[] array no longer
trailing - which means the offset of the 'token' field depends
on the rank of the array.

The dim[] field is even optional when dim + codimen == 0 and that
case indeed happens (ah, via get_scalar_to_descriptor_type).
So much for re-using this combo ;)

I suppose we can compensate for this by dynamically computing the
offset of the 'token' field but then it's not obvious to me
where the total 'rank' is stored inside the descriptor or how
the 'token' field is accessed for assumed-shape arrays - the
current method by simple field chaining definitely won't work.

Anyway, I'll try to deal with all this by just adjusting the TBAA
type but not the access type leaving that alone.

IMHO the cleanest way would be to swap the CAF token field and
the dim[] field (which is an ABI change for -fcoarray)

Richard.

Reply via email to