[Patch, Fortran] First ASSOCIATE patch and some questions / RFCs

[Daniel Kraft]

Hi all,

attached is my first patch on the way of implementing the ASSOCIATE 
construct.  See the test-cases for what it is supposed to do.  Not yet 
working are basically two things:


* Association of names to variables (currently only expressions).  I 
think that my original idea of replacing each occurrence directly in the 
parser with the corresponding gfc_expr does not work, because it will do 
the wrong thing if the selector expression changes, as in these two cases:

INTEGER, POINTER :: ptr
ptr => something
ASSOCIATE (x => ptr)
   ptr => something else
   ! x should still refer to something
END ASSOCIATE

INTEGER :: n
REAL :: array(10)
n = 2
ASSOCIATE (arr => array(n : n+2)
   n = 5
   ! arr is still array(2 : 4)
END ASSOCIATE

(At least if I read the standard correctly.)  So instead we need another 
strategy; possibly using a BLOCK local pointer that it pointed to the 
selector.

Does this provoke problems, when the selector is not TARGET or the like? 
  But I think we're already doing something like that for SELECT TYPE at 
the moment -- Janus, can the current implementation be used for the 
general ASSOCIATE case, too?  Or does it only work for polymorphism?


* Association to array expressions.  The problem here is that for 
something like:

INTEGER :: array(10)
ASSOCIATE (doubled => 2 * array)
   PRINT *, doubled(2)
END ASSOCIATE

During parsing, the expression "2 * array" seems not to have its rank 
defined yet; this is only done at resolution stage.  However, when 
parsing doubled(2), the compiler already needs to know that doubled is 
an array!  Any ideas what we could do here?

Otherwise, I think that with the ability of BLOCK to declare 
"dynamically sized" arrays (like VLA's in C) we can easily generate a 
correctly shaped local variable to hold the results whenever necessary.


On the other side, basic association to scalar expressions seems already 
to work quite well.  I've still two positions marked "XXX" in the patch 
I'd also like to get another opinion on:

First, when calling gfc_get_sym_tree to insert a symbol into the current 
namespace, in theory this function may return a failure code.  However, 
I'm not sure what to do in this case; especially, a grep of the source 
shows that it is already used without checking for the return value at 
all in different places.  So:  When may it precisely fail and what's the 
guideline to follow here?  Is it ok to call it without check, is the 
gcc_unreachable() check as in my patch ok, or do we have to deal and 
correctly handle a failure?  If so, should the other places also be 
updated to do so?

Second, is primary.c:match_variable the place that handles what the 
standard calls a "variable definition context"?  It seems to be so, at 
least for the basic handling.  Or is there already some other routine to 
check that?  Do I have to implement my own to be fully correct?


The patch was regression-tested on GNU/Linux-x86-32. 
array_constructor_11.f90 failed with -O3 -g, but I don't see how this 
could be related to my patch...  Does anyone else see this?  If so, ok 
for trunk?

Thanks,
Daniel

-- 
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.changelog
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100606/0ac5b0c0/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100606/0ac5b0c0/attachment-0001.ksh>