ASSOCIATE: Getting array-spec for expression

[Daniel Kraft]

Hi Tobias and all,

at the moment, the (very limited) ASSOCIATE support does not allow 
association to array expressions like:

INTEGER :: a(5), b(5)
ASSOCIATE (c => a + b)
   ...
END ASSOCIATE

I'm right now trying to get this working; however, I'm stuck at the 
moment.  The problem is that because "c" is internally a variable (with 
corresponding gfc_symbol), I have to create a fitting gfc_array_spec for 
it so that the rest of gfortran knows how to deal with expressions 
involving "c".

However, for the gfc_expr "a + b" I do not have such; what I do have is 
the expression's rank and shape -- although it says in gfortran.h that 
shape may even be NULL if unknown at compile-time.  So it seems that all 
I can count on is the rank.

The standard specifies that the bounds of "c" should be LBOUND/UBOUND of 
"a + b".  It does not specify (or I did not find) which type the array 
is of (like explicit, assumed-shape, deferred, ...).  So is all I can do 
set as->type = AS_UNKNOWN?  But I think that AS_EXPLICIT may be also ok 
because when the association is done, the shape is explicitely known as 
"LBOUND(a + b) : UBOUND(a + b)".

But:  It seems that for a program like:

   INTEGER :: a(5), b(5)
   a = ...
   b = ...
   PRINT *, LBOUND (a + b), UBOUND (a + b)
END

Array-temporaries are created, the sums calculated and only then the 
bounds returned!  Is this just a missed optimization?  Could we simplify 
LBOUND/UBOUND by looking at the two summands and take just the first's 
bounds (because they have to have the same shape)?  But if so, does this 
work in any case or are there situations where some array expression has 
to be actually calculated in order to evaluate LBOUND/UBOUND?

I think for the purpose of finding the correct bounds in association, it 
would be total overkill to calculate the sum; or even multiple times... 
  So I surely can not just create the bounds in the array-spec as 
expressions involving LBOUND/UBOUND.

Do you have any ideas how to nicely and cleanly implement that?  Maybe 
I've just missed something...  Can we get around without creating the 
array-spec, or is this absolutely necessary?  (But I guess it is.)

All I can think about as solution for now would be to somehow create 
some special expressions as bounds and when trans'ing go just with the 
one internal array created for "c" anyway and use that to get the 
bounds, too (if this is easily possible).

Or maybe, we should think about a clean way to generate "temporary 
arrays" in the front-end anyways, which can also be used for generating 
associate target expressions.  This is something which is necessary (I 
think) to implement FINAL in the front-end -- I'm not sure whether we 
should do this or try doing stuff in trans, but it would probably make 
things easier and clearer.

I hope this was somewhat understandable and clear...  And am really 
looking forward to some ideas!

Yours,
Daniel

-- 
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri