Re: [gomp merge] Fortran FE changes from gomp branch not dependent on OpenMP

[Paul Brook <paul at codesourcery dot com>]

On Wednesday 18 January 2006 20:44, Jakub Jelinek wrote:
> On Wed, Jan 18, 2006 at 08:07:47PM +0000, Paul Brook wrote:
> > I'll take a look at the patch.
> > Could you explain in general terms what you're trying to achieve?
>
> Ensure that whenever possible (i.e. with the exception of assumed size
> arrays) all ARRAY_TYPEs passed to the middle-end have complete types.
> Currently, if the arrays (or CHARACTER vars/params or arrays of CHARACTER)
> have constant length, they are complete, but otherwise they have usually
> incomplete type, no TYPE_SIZE{,_UNIT}, no upper bound on TYPE_DOMAIN, etc.
> While gfortran could sort of live without it till now, OpenMP handling in
> the middle-end relies on the types and decls to be complete, so that it
> can privatize them.

Are you sure you're doing the right thing with assumed shape arrays? These may 
be discontiguous. To fix this properly we probably need to avoid flattening 
arrays.

> > The fortran frontend DOES create GENERIC trees. We only gimplify before
> > passing to the backend because middle-end bits broke when we didn't.
>
> In the C/C++ FEs, such upper bounds are represented by arbitrarily huge
> GENERIC trees which are surrounded into SAVE_EXPR, with a DECL_EXPR
> to say where vars with that type are declared and the middle-end then
> gimplifies when needed.
> In Fortran, the array sizes can be also quite complex, but trans-expr.c
> often creates temporary variables when converting front-end trees to
> GENERIC trees and furthermore many of the sizes depend on the value
> of other variables, initialized during gfc_trans_deferred_vars.
> So a part of my patch (gfc_trans_vla_type_sizes and its callers)
> "gimplifies" TYPE_DOMAIN and TYPE_SIZE* by hand at the point in
> gfc_trans_deferred_vars when the variables it uses are already
> initialized.

Hmm, ok. I'm not sure using "gimplicifation" to describe this is a good idea 
though.

Paul