Le 06/04/2014 20:30, Tobias Burnus a écrit :
> Mikael Morin wrote:
>> Argh. great. What about the use_assoc thing? Why is that needed?
>
> Frankly, I don't know. In terms of the code, the problem is that
> attr.use_assoc is zero and, hence, the compiler generates a call to some
> external version
Mikael Morin wrote:
Argh. great. What about the use_assoc thing? Why is that needed?
Frankly, I don't know. In terms of the code, the problem is that
attr.use_assoc is zero and, hence, the compiler generates a call to some
external version which lacks the module name - that symbol is not fou
Le 06/04/2014 19:46, Tobias Burnus a écrit :
> Mikael Morin wrote:
>> Le 06/04/2014 18:05, Tobias Burnus a écrit :
>>> It is supposed to propagate the information whether any of the
>>> components ("c") has a derived type. However, I made a typo: It
>>> should be "&has_final2" instead of "&has_fina
Mikael Morin wrote:
Le 06/04/2014 18:05, Tobias Burnus a écrit :
It is supposed to propagate the information whether any of the
components ("c") has a derived type. However, I made a typo: It
should be "&has_final2" instead of "&has_final".
gfc_is_finalizable couldn't be used?
No that requi
Hello,
Le 06/04/2014 18:05, Tobias Burnus a écrit :
> Bernhard Reutner-Fischer wrote:
>> On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
>>> +bool has_final2 = false;
>>> +if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final))
>>> + return false; /* Err
Bernhard Reutner-Fischer wrote:
On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
+ bool has_final2 = false;
+ if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final))
+ return false; /* Error. */
+ has_final = has_final || has_final2;
On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
> This patch ensures that the finalization expression is generated and that
> use-associated finalizers are properly accessed.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
> 2014-04-04 Tobias Burnus
This patch ensures that the finalization expression is generated and
that use-associated finalizers are properly accessed.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-04-04 Tobias Burnus
PR fortran/58880
PR fortran/60495
* resolve.c (gfc_resolve_finalizers): En
