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

[Daniel Kraft]

Hi,

here's an updated version of my patch addressing Tobias' comments. 
Namely, I changed the co-indexed check to an error message, added the 
CRITICAL back in the comment where it disappeared, removed ST_CRITICAL 
in addition to ST_BLOCK (see Tobias' last message; but I can also let 
this change out entirely if you want) and added a test for the 
"unexpected data declaration statement" in associate_3.f03.

I plan to re-regtest and commit tomorrow or Thursday, after the merge is 
settled for some time.  What's about the "variable definition context" 
thing?  I think it should be ok to just remove the XXX comment.  I can 
also change it to a FIXME / TODO, though, if we want to investigate this 
further.

Yours,
Daniel

Daniel Kraft wrote:
> 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/20100608/9408c4ba/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100608/9408c4ba/attachment-0001.ksh>