Dear all,
in attachment the new draft which also supports the polymorphic
deallocation via INTENT(OUT). Tomorrow I'll try to realize a draft for
the deallocation at the end of the scope.
Regards
2012/6/12 Alessandro Fanfarillo :
> I don't know if there's already a PR but I get an ICE compiling t
I don't know if there's already a PR but I get an ICE compiling this
with a non-patched version. If x is not an array everything goes ok.
2012/6/11 Tobias Burnus :
> On 06/11/2012 11:24 AM, Alessandro Fanfarillo wrote:
>>
>> gfortran.dg/coarray/poly_run_3.f90
>
>
> That one fails because I for for
On 06/11/2012 11:24 AM, Alessandro Fanfarillo wrote:
gfortran.dg/coarray/poly_run_3.f90
That one fails because I for forgot that se.expr in gfc_trans_deallocate
contains the descriptor and not the pointer to the data. That's fixed by:
tmp = se.expr;
if (GFC_DESCRIPTOR_TYP
Thank you for the review, with this patch I get some ICEs during the
regstest with:
gfortran.dg/coarray/poly_run_3.f90
gfortran.dg/elemental_optional_args_5.f03
gfortran.dg/select_type_26.f03
gfortran.dg/select_type_27.f03
gfortran.dg/class_48.f90
gfortran.dg/class_allocate_10.f03
gfortran.dg/clas
Alessandro Fanfarillo wrote:
with the priceless support of Tobias I've almost realized the patch
for this PR. In attachment there's the second draft. During the
regression test I have only one error with select_type_4.f90. The
problem is in the destroy_list subroutine when it checks
associated(no
Hi all,
with the priceless support of Tobias I've almost realized the patch
for this PR. In attachment there's the second draft. During the
regression test I have only one error with select_type_4.f90. The
problem is in the destroy_list subroutine when it checks
associated(node) after the first dea
Hi Alessandro,
I am glad to see that Janus is giving you a helping hand, in addition
to Tobias. I am so tied up with every aspect of life that gfortran is
not figuring much at all.
When you clean up the patch, you might consider making this into a
separate function:
+ if (free_proc)
+
> Right, the problem is that the _free component is missing. Just as the
> _copy component, _free should be present for *every* vtype, no matter
> if there are allocatable components or not. If the _free component is
> not needed, it should be initialized to EXPR_NULL.
With an "empty" _free functi
2012/6/2 Tobias Burnus :
> Alessandro Fanfarillo wrote:
>>
>> The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it
>> calls the __free_s_bar_mod_S_bar function instead of the proper
>> doit().
>
>
> That kind of mak
Hi,
> By contrast, I assume that you (Janus) build GCC with the C compiler, i.e.
> you configure with --disable-build-poststage1-with-cxx.
actually I used --disable-bootstrap, which also has the effect that
gfortran is built with the C compiler.
> Thus, a default boot strap, shouldn't fail. No
Alessandro Fanfarillo wrote:
The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it
calls the __free_s_bar_mod_S_bar function instead of the proper
doit().
That kind of makes sense: "foo" has no allocatable component
Janus Weil wrote:
The patch actually gives a few warnings:
Looking at those warnings, they seem to be valid C++ but invalid C89. As
Stages 2 and 3 are, by default, compiled by C++, I assume that
Alessandro does not see those.
By contrast, I assume that you (Janus) build GCC with the C compi
Hi,
>> Sorry, I don't understand the last sentence. Why should it call some
>> "__free..." instead of "doit"? And why is that test case even affected
>> by your patch (you said it would only work with explicit DEALLOCATE,
>> which does not appear in that test case)?
>
> Yes, it is as I said... In
Hi Janus,
> Sorry, I don't understand the last sentence. Why should it call some
> "__free..." instead of "doit"? And why is that test case even affected
> by your patch (you said it would only work with explicit DEALLOCATE,
> which does not appear in that test case)?
Yes, it is as I said... In
h
Hi Alessandro,
> I have realized a draft patch for the PR 46321, currently it works
> only with the explicit DEALLOCATE.
thanks for the patch! Some first comments without actually looking at
the patch in detail ...
> Running the regression tests it doesn't pass the following:
>
> - gfortran.dg/
Dear all,
I have realized a draft patch for the PR 46321, currently it works
only with the explicit DEALLOCATE.
Running the regression tests it doesn't pass the following:
- gfortran.dg/class_19.f03 (too much "__builtin_free")
- gfortran.dg/auto_dealloc_2.f90 (too much "__builtin_free")
- gfortr
16 matches
Mail list logo
