[Patch, Fortran] F2003: More ASSOCIATE stuff

[Daniel Kraft]

Tobias Burnus wrote:
>  Daniel Kraft wrote:
>> here's another ASSOCIATE patch.  It shifts handling of the variables 
>> and their initialization to the trans-* phase.  This fixes the 
>> problems with array boundaries and implements association to 
>> variables.  I think most of the useful stuff should work with this now.
> Awesome!
> 
>> What does not work [...] is association to strings. [...]
>> parsing of component references if you associate a variable to a 
>> derived-type value
> (The latter is a rather important case, looking at my Fortran 2003 books 
> ...)
> 
> You can add to the list: Polymorphic types. The following example is 
> rejected with:

Yes, I forgot about those (when writing the email).  You're right of 
course, this is something to also still consider.  As well as updating 
SELECT_TYPE support.

> I also would expect an error for:
> 
> subroutine test(x)
>   integer, intent(in) :: x
>   associate ( y => x)
>     y = 7
>   end associate
> end subroutine test
> 
> due to the INTENT(IN).

This is what I meant (and other stuff) with the variable definition 
context "enhancement" -- although I really wonder whether we can use 
this to put other errors together as well (for other things that are 
"read-only").  The same restrictions are valid for INTENT(IN) variables 
themselves or PARAMETERs, for instance -- so I'd try to implement some 
general concept of variable definition context in order to unify and fix 
this.  If that's ok, in a seperate patch.

>> I saw two failures, namely array_memcpy_3.f90 and bind_c_dts_3.f90.  
>> Is this currently broken?
> 
> I saw them as well - though the array_memcpy_3.f90 looked a bit spurious 
> - especially, I got either a MEMREF or memcopy. With bind_c_dts_3.f90, I 
> wonder whether this is due to my recent DT bugfix. I thought I fixed 
> that before the committal - can you try to find out why you see this? 
> Maybe do an "svn up" in gcc/testsuite/gfortran.dg to make sure your file 
> is up to date.

I thought I did a uniform update, but probably only svn up gcc/fortran 
before my last committal and no test-suite update -- the BIND(C) stuff 
is fixed now, thus I guess we can see this as no regressions.

>> Ok for trunk when this is figured out?
> 
> OK, but I have one nit:
> 
> +      gfc_error ("'%s' at %L associated to %s can not"
> +             " be used in a variable definition context",
> +             sym->name,&sym->declared_at,
> +             (target->expr_type == EXPR_VARIABLE
> +              ? "vector-indexed target" : "expression"));
> 
> 
> Can you split this into two gfc_errors? I think we make the live for the 
> translators much easier if we do not use %s + a string.

I wondered about this, myself.  My rationale for why I thought it is not 
too bad was that the expressions inserted are somewhat "complete 
expressions" specifying "a thing" -- and thus it should be hopefully 
possible to translate this constructions (or the individual strings). 
But you're probably right (and I don't have any translation experience), 
so I'll change that.

> More general remark, not preventing the committal:
> 
> +  ASSOCIATE (a =>  5,&  ! { dg-error "variable definition context" }
> +             b =>  arr((/ 1, 3 /))) ! { dg-error "variable definition 
> context" }
> +    a = 4
> +    b = 7
> 
> 
> At least for long ASSOCIATE blocks, I think it would be more helpful to 
> have the error in the "a = 4" line and not in the "a => 5" line.

This could also be fixed with my plans abuot variable definition 
contexts.  I agree it is helpful, but I don't see how to do this 
reliably with the current code -- at least not without adding special 
fields like "position of usage where variable flag was set" to the data 
structures which seems not like the best idea to me.  Instead, I'd like 
to go for the variable definition context.

So do you agree with committing when I've split the error message?

Yours,
Daniel

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