This is the mail archive of the
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR51870 - [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS
- From: Tobias Burnus <burnus at net-b dot de>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: fortran at gcc dot gnu dot org, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 23 Jan 2012 00:14:30 +0100
- Subject: Re: [Patch, fortran] PR51870 - [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS
- References: <CAGkQGi+30+UeX6FSDqtQqTVwz+V678r8G23nbAJ4yRZ+x=fZJg@mail.gmail.com>
Paul Richard Thomas wrote:
The attached is quite straightforward - for non-variable class STATUS
I believe that you mean source-expr (i.e. SOURCE= and MOLD=) and not STATUS.
Note that I have begged off including variables in this process, given
the stage that we are at with 4.7.0.
That's appreciated. I think that 4.7 will be released relatively
soonish, given that there are just 83 serious regressions (9 P1, 66 P2,
8 P3; 63 P4, 56 P4). The plan was to release around mid-March to
beginning of April. Given the low number of regressions, it might be
slightly earlier, though not much as the release managers want to give
users some time to find more regressions.
This means that the patch only affects the part that was broken. Early in 4.8.0, gfc_trans_allocate will have to undergo a massive clean up.
Clean-ups are also appreciated ;-)
* * *
I somehow liked your draft patch more:
* The big program which I reduced to the test case in PR 51870 fails
with the current patch - only the reduced test case of the PR works. The
failure of the bigger program is - at runt time - a SIGABRT at
#6 0x409175 in __show_class_MOD___copy_show_class_Show
* It also fixed PR 48705. Your current patch fixes the reduced test case
(comment 1) of that PR, but no longer the original version, which fails
at the end of the program ("end program" line) at run time (SIGABRT).
Invalid write of size 8
at 0x4009B3: __generic_deferred_MOD___copy_generic_deferred_Vec (in
(I assume both programs have the same issue.)
Thus, I would prefer if you could have a look at the latter PR.
2012-01-22 Paul Thomas<firstname.lastname@example.org>
Could you also add PR fortran/51943 and PR 51946? (I think those are
effectively the same examples. Also the full example
ssdSource/chapter08/puppeteer_f2003 works for me.)
+ /* This is the safest way of converting to a compatible
+ type for use in the allocation. */
+ tmp = TYPE_SIZE_UNIT (TREE_TYPE (gfc_index_zero_node));
+ memsz = fold_convert (TREE_TYPE (tmp), memsz);
+ memsz = fold_convert (size_type_node, memsz);
/* Determine allocate size. */
- if (al->expr->ts.type == BT_CLASS && code->expr3)
+ if (al->expr->ts.type == BT_CLASS
+ && code->expr3
+ && memsz == NULL_TREE)
Indentation looks wrong.
for (al = code->ext.alloc.list; al != NULL; al = al->next)
+ class_expr = build_fold_indirect_ref_loc (input_location,
+ class_expr = gfc_evaluate_now (class_expr, &se.pre);
I have the feeling that you evaluate the function multiple times.
allocate(kernel, kernel2, mold=executive_producer%create_show() )
D.1890 = create_show ();
(struct __vtype_show_producer_class_Integrand *) kernel._vptr =
(struct __vtype_show_producer_class_Integrand *) D.1890._vptr;
(void) __builtin_memcpy ((void *) kernel._data, (void *)
&create_show (), 4);
D.1892 = create_show ();
(struct __vtype_show_producer_class_Integrand *) kernel2._vptr
= (struct __vtype_show_producer_class_Integrand *) D.1892._vptr;
(void) __builtin_memcpy ((void *) kernel2._data, (void *)
&create_show (), 4);
Thus, one evaluates the function 4 times instead of only once.
Additionally, MOLD= does not invoke the default initializer (as expected
for MOLD=) but memcopy (as expected for SOURCE=).
The memcpy is also wrong. If CLASS(integrand) (of create_show) returned
a derived type with allocatable components, one had to to a deep copy.
As this is not known at compile time, a call to vtab->__copy is required.
And a last issue: If one changes in
type(show_producer), allocatable :: executive_producer
the TYPE to CLASS one gets still an ICE in conv_function_val.
* Ditto for SOURCE=, though there one runs into PR51953 as F2003 only
allowed one allocate-object.