[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from janus at gcc dot gnu.org 2010-11-05 18:41:37 UTC --- r166368 fixes the deep copy issue and makes the original test case give the correct output.
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 --- Comment #17 from janus at gcc dot gnu.org 2010-11-05 18:15:02 UTC --- Author: janus Date: Fri Nov 5 18:14:52 2010 New Revision: 166368 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166368 Log: 2010-11-05 Janus Weil PR fortran/45451 PR fortran/46174 * class.c (gfc_find_derived_vtab): Improved search for existing vtab. Add component '$copy' to vtype symbol for polymorphic deep copying. * expr.c (gfc_check_pointer_assign): Make sure the vtab is generated during resolution stage. * resolve.c (resolve_codes): Don't resolve code if namespace is already resolved. * trans-stmt.c (gfc_trans_allocate): Call '$copy' procedure for polymorphic ALLOCATE statements with SOURCE. 2010-11-05 Janus Weil PR fortran/45451 PR fortran/46174 * gfortran.dg/class_19.f03: Modified. * gfortran.dg/class_allocate_6.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_6.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_19.f03
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 Tobias Burnus changed: What|Removed |Added Depends on||46174 --- Comment #16 from Tobias Burnus 2010-10-26 07:35:44 UTC --- The test case of comment 4 is now fixed, namely: ALLOCATE (polymorphic, SOURCE=non-polymorphic) Unfixed is a polymorphic SOURCE= as this requires a deep copying of the effective type, cf. PR 46174. Consequently, the first test case (attachment 21592) will fail at allocate(a%a,source=b, stat=info) if "b" has any allocatable components. That's the case if "b" is of the effective type "psb_d_csr_sparse_mat". Interestingly, wrapping the ALLOCATE in select type (b) type is (psb_d_csr_sparse_mat) allocate(a%a,source=b, stat=info) end select does not help :-( I do not know whether this SOURCE= problem is the only or only the main bug exposed by the first test case. * * * Unfixed is the diagnostic of passing a non-polymorphic actual to an *allocatable* polymorphic dummy. That accepts-invalid bug is PR 46161 and affects the second attachment (attachment 21613).
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 --- Comment #15 from Tobias Burnus 2010-10-26 06:49:47 UTC --- Author: burnus Date: Tue Oct 26 06:49:43 2010 New Revision: 165936 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165936 Log: 2010-10-26 Tobias Burnus PR fortran/45451 * trans-stmt.c (gfc_trans_allocate): Do a deep-copy for SOURCE=. PR fortran/43018 * trans-array.c (duplicate_allocatable): Use size of type and not the size of the pointer to the type. 2010-10-26 Tobias Burnus PR fortran/45451 * gfortran.dg/class_allocate_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 --- Comment #14 from Tobias Burnus 2010-10-24 22:31:19 UTC --- (In reply to comment #13) > The following works - though I am not sure whether it is the correct patch. > Janus, what do you think? I mean in particular gfc_expr_to_initialize (expr) vs. expr and questions regarding the default initializer. Further comments: a) The first example (attachment 21592) produces the correct numbers (or at least the same as Cray and as in comment 3). Also in comment 0 the numbers are OK for the the valgrind run - only the ones of the non-valgrind run were wrong. If one uses GLIBC's MALLOC checks the program still segfaults; valgrind shows a failure for: Conditional jump or move depends on uninitialised value(s) at 0x4EF7FD2: _gfortran_move_alloc (move_alloc.c:40) by 0x400C8C: __psb_d_csr_mat_mod_MOD_psb_d_mv_csr_from_fmt (long1.f90:238) which is if (to->data) and call move_alloc(b%irp, a%irp) if one checks the allocation status of "b%irp" after the mvoe_alloc call, the result is "T" rather than the expect "F". b) The second example (attachment 21613) fails with crayftn at it is invalid. (In "call doit(atx,acsr)" the second argument is TYPE instead of CLASS as the *allocatable* dummy is.) gfortran does not detect this. -- See new PR 46161.
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 --- Comment #13 from Tobias Burnus 2010-10-24 21:42:33 UTC --- (In reply to comment #12) > If one looks at the dump Scratch that part. In one case one allocates the component (integr(4)*4) in the other case the type, i.e. the array descriptor. The actual issue is that only a shallow copy is done: (void) __builtin_memcpy ((void *) a.$data, (void *) &acsr, 48); Thus, a.$data->irp.data and acsr.irp.data point to the same memory. Of course, this will fail at finally if (acsr.irp.data != 0B) __builtin_free ((void *) acsr.irp.data); if (a.$data != 0B) if (a.$data->irp.data != 0B) __builtin_free ((void *) a.$data->irp.data); The problem is in trans-stmt.c's gfc_trans_allocate: if (code->expr3 && !code->expr3->mold) { /* Initialization via SOURCE block (or static default initializer). */ gfc_expr *rhs = gfc_copy_expr (code->expr3); if (al->expr->ts.type == BT_CLASS) [...] tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz); } else tmp = gfc_trans_assignment (gfc_expr_to_initialize (expr), rhs, false, false); The gfc_trans_assignment properly takes care of allocatable components (cf. PR 43018) while a simple memcopy does not. The following works - though I am not sure whether it is the correct patch. Janus, what do you think? --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -4489,15 +4489,9 @@ gfc_trans_allocate (gfc_code * code) gfc_expr *rhs = gfc_copy_expr (code->expr3); if (al->expr->ts.type == BT_CLASS) { - gfc_se dst,src; if (rhs->ts.type == BT_CLASS) gfc_add_component_ref (rhs, "$data"); - gfc_init_se (&dst, NULL); - gfc_init_se (&src, NULL); - gfc_conv_expr (&dst, expr); - gfc_conv_expr (&src, rhs); - gfc_add_block_to_block (&block, &src.pre); - tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz); + tmp = gfc_trans_assignment (expr, rhs, false, false); } else tmp = gfc_trans_assignment (gfc_expr_to_initialize (expr),
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #12 from Tobias Burnus 2010-10-24 19:56:08 UTC --- (In reply to comment #4) > Ok, I could reduce this quite a bit: > allocate(acsr%irp(4)) > allocate(a,source=acsr) If one looks at the dump, one sees a similar problem to PR 43018. For the first allocate, one has: D.1530 = (void * restrict) __builtin_malloc (16); which makes sense: 4 * integer(4) = 16 byte. However, for the second allocate one sees: D.1532 = (void * restrict) __builtin_malloc (48); which might be OK. However, the following is definitely invalid - and causes here a segfault (void) __builtin_memcpy ((void *) a.$data, (void *) &acsr, 48);
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 --- Comment #11 from Salvatore Filippone 2010-10-05 19:39:44 UTC --- (In reply to comment #4) > Ok, I could reduce this quite a bit: > > >1 3 4 5 >1 3 4 5 >0 0 4 5 > > The last line here should be the same as the first two. Changing the CLASS > variable into a TYPE makes it work. Running through valgrind shows: > Strange thing is that guarding with a SELECT TYPE statement as in === allocate(a,source=acsr) write(*,*) acsr%irp(:) select type(aa=>a) type is (psb_base_sparse_mat) call move_alloc(acsr%irp, aa%irp) write(*,*) aa%irp(:) class default write(*,*) 'Wrong class default' end select still gives the wrong answer [sfili...@localhost bug23]$ ./bug23_janus 1 3 4 5 1 3 4 5 0 0 4 5
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 12:02 --- I think this is a variant of PR 42647: Allocatable components of allocatable scalars are not correctly handled. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42647 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #9 from sfilippone at uniroma2 dot it 2010-08-31 19:21 --- Created an attachment (id=21613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21613&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #8 from sfilippone at uniroma2 dot it 2010-08-31 19:20 --- (In reply to comment #7) > (In reply to comment #6) > > Fine. Waiting for it > Consider the following variation: upon exit from DOIT, the ACSR variable should be deallocated (since it was MOVE_ALLOCed to atx%a) but it is not, hence double free. === [sfili...@localhost bug23]$ ./bug23_1 Allocation status acsr: T Allocation status atx: T T T 1 3 4 5 1 1 2 3 0 0 0 0 0 0 0 0 1.1.2. 3.0.0. 0.0.0. 0.0.0. *** glibc detected *** ./bug23_1: double free or corruption (!prev): 0x023bbfe0 *** === Backtrace: = /lib64/libc.so.6[0x3d69675676] ./bug23_1[0x401876] ./bug23_1[0x4018da] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3d6961ec5d] ./bug23_1[0x400869] === Memory map: 0040-00402000 r-xp 08:05 2187330 /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug23/bug2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-31 14:18 --- (In reply to comment #6) > > Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now > MOLD works only with non-polymorphic expressions. Once the PR is fixed, > polymorphics should work too. Until this has happened, please refrain from > opening further PRs on MOLD. > Fine. Waiting for it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-31 14:17 --- (In reply to comment #5) > In the meantime, I tried with MOLD= in place of SOURCE=, and in the full > application it still gives a segfault; I think that variant should be checked > as well. Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now MOLD works only with non-polymorphic expressions. Once the PR is fixed, polymorphics should work too. Until this has happened, please refrain from opening further PRs on MOLD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-31 14:04 --- (In reply to comment #4) > Ok, I could reduce this quite a bit: > Good :) In the meantime, I tried with MOLD= in place of SOURCE=, and in the full application it still gives a segfault; I think that variant should be checked as well. Actually, MOLD= is preferrable for the kind of thing I am doing, but since it's an F2008 feature I had to put it under IFDEF for the time being. Salvatore -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-30 20:48 --- Ok, I could reduce this quite a bit: program bug23 implicit none type :: psb_base_sparse_mat integer, allocatable :: irp(:) end type psb_base_sparse_mat class(psb_base_sparse_mat), allocatable :: a type(psb_base_sparse_mat) :: acsr allocate(acsr%irp(4)) acsr%irp(1:4) = (/1,3,4,5/) write(*,*) acsr%irp(:) allocate(a,source=acsr) write(*,*) a%irp(:) call move_alloc(acsr%irp, a%irp) write(*,*) a%irp(:) end program bug23 Executing gives: 1 3 4 5 1 3 4 5 0 0 4 5 The last line here should be the same as the first two. Changing the CLASS variable into a TYPE makes it work. Running through valgrind shows: ==11502== Command: ./a.out ==11502== 1 3 4 5 1 3 4 5 ==11502== Invalid read of size 4 ==11502==at 0x4EE59B8: extract_int (write.c:450) ==11502==by 0x4EE67B1: write_integer (write.c:1260) ==11502==by 0x4EE9BDE: _gfortrani_list_formatted_write (write.c:1552) ==11502==by 0x4EDECA7: _gfortran_transfer_array (transfer.c:2000) ==11502==by 0x400B07: MAIN__ (in /home/jweil/GSoC/PRs/45451/a.out) ==11502==by 0x400BA8: main (in /home/jweil/GSoC/PRs/45451/a.out) ==11502== Address 0x5934360 is 0 bytes inside a block of size 16 free'd ==11502==at 0x4C280BD: free (vg_replace_malloc.c:366) ==11502==by 0x4EEF5A8: _gfortran_move_alloc (move_alloc.c:41) ==11502==by 0x400AAC: MAIN__ (in /home/jweil/GSoC/PRs/45451/a.out) ==11502==by 0x400BA8: main (in /home/jweil/GSoC/PRs/45451/a.out) ==11502== 1 3 4 5 ==11502== ==11502== HEAP SUMMARY: ==11502== in use at exit: 0 bytes in 0 blocks ==11502== total heap usage: 18 allocs, 18 frees, 3,844 bytes allocated ==11502== ==11502== All heap blocks were freed -- no leaks are possible ==11502== ==11502== For counts of detected and suppressed errors, rerun with: -v ==11502== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 4 from 4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
-- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-08-30 16:31:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #3 from sfilippone at uniroma2 dot it 2010-08-30 12:13 --- And here is the (expected) output with XLF. [snfi...@josquin ~]$ xlf2003_r -o bug23 bug23.f03 ** psb_const_mod === End of Compilation 1 === ** psb_base_mat_mod === End of Compilation 2 === ** psb_d_base_mat_mod === End of Compilation 3 === ** psb_d_csr_mat_mod === End of Compilation 4 === ** psb_d_mat_mod === End of Compilation 5 === ** bug23 === End of Compilation 6 === 1501-510 Compilation successful for file bug23.f03. [snfi...@josquin ~]$ ./bug23 New version Allocation status: T T T 1 3 4 5 1 1 2 3 0 0 0 0 0 0 0 0 1.0 1.0 2.0 3.0 0.00E+00 0.00E+00 0.00E+00 0.00E+00 0.00E+00 0.00E+00 0.00E+00 0.00E+00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #2 from sfilippone at uniroma2 dot it 2010-08-30 12:12 --- (In reply to comment #0) > Hello, > After a lot (a LOT) of work, I've come up with this test case. The test case > *appears* to run fine, but valgrind shows something is amiss, and in the full > application (much more complex) there follow multiple segfaults. I did not > find > (so far) a way to have a test case both small and exibiting the error out of > valgrind, hope you'll pardon me. > The error: the ALLOCATABLE components of the ATX%A variable are detected as > ALLOCATED, and seemingly are printed OK, but VALGRIND says they were already > freed. > > Should be more careful before talking: the output is visibly wrong. > [sfili...@donald bug23]$ ./bug23 > New version > Allocation status: T T T >0 0 4 5 >0 0 2 3 0 0 > >0 0 0 0 0 0 >0.1.2. > > 3.0.0. > 0.0.0. > 0.0.0. > [sfili...@donald bug23]$ valgrind ./bug23 > ==6940== Memcheck, a memory error detector > ==6940== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. > ==6940== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info > ==6940== Command: ./bug23 > ==6940== > New version > Allocation status: T T T > ==6940== Invalid read of size 4 > ==6940==at 0x4CC19B8: extract_int (write.c:450) > ==6940==by 0x4CC27B1: write_integer (write.c:1260) > ==6940==by 0x4CC5BDE: _gfortrani_list_formatted_write (write.c:1552) > ==6940==by 0x4CBACA7: _gfortran_transfer_array (transfer.c:2000) > ==6940==by 0x401834: MAIN__ (bug23.f03:308) > ==6940==by 0x40197A: main (bug23.f03:284) > ==6940== Address 0x5141450 is 0 bytes inside a block of size 16 free'd > ==6940==at 0x4A04D72: free (vg_replace_malloc.c:325) > ==6940==by 0x4CCB5A8: _gfortran_move_alloc (move_alloc.c:41) > ==6940==by 0x400B90: __psb_d_csr_mat_mod_MOD_psb_d_mv_csr_from_fmt > (bug23.f03:238) > ==6940==by 0x401449: __psb_d_mat_mod_MOD_psb_d_mv_from (bug23.f03:277) > ==6940==by 0x4016C6: MAIN__ (bug23.f03:302) > ==6940==by 0x40197A: main (bug23.f03:284) > ==6940== >1 3 4 5 >1 1 2 3 0 0 > >0 0 0 0 0 0 > ==6940== Invalid read of size 8 > ==6940==at 0x4CC3795: write_float (write_float.def:1050) > ==6940==by 0x4CC508C: _gfortrani_write_real (write.c:1470) > ==6940==by 0x4CC5BAE: _gfortrani_list_formatted_write (write.c:1561) > ==6940==by 0x4CBACA7: _gfortran_transfer_array (transfer.c:2000) > ==6940==by 0x401904: MAIN__ (bug23.f03:310) > ==6940==by 0x40197A: main (bug23.f03:284) > ==6940== Address 0x5141510 is 0 bytes inside a block of size 96 free'd > ==6940==at 0x4A04D72: free (vg_replace_malloc.c:325) > ==6940==by 0x4CCB5A8: _gfortran_move_alloc (move_alloc.c:41) > ==6940==by 0x400BDC: __psb_d_csr_mat_mod_MOD_psb_d_mv_csr_from_fmt > (bug23.f03:240) > ==6940==by 0x401449: __psb_d_mat_mod_MOD_psb_d_mv_from (bug23.f03:277) > ==6940==by 0x4016C6: MAIN__ (bug23.f03:302) > ==6940==by 0x40197A: main (bug23.f03:284) > ==6940== >1.1.2. > > 3.0.0. > 0.0.0. > 0.0.0. > ==6940== > ==6940== HEAP SUMMARY: > ==6940== in use at exit: 0 bytes in 0 blocks > ==6940== total heap usage: 33 allocs, 33 frees, 4,938 bytes allocated > ==6940== > ==6940== All heap blocks were freed -- no leaks are possible > ==6940== > ==6940== For counts of detected and suppressed errors, rerun with: -v > ==6940== ERROR SUMMARY: 28 errors from 2 contexts (suppressed: 6 from 6) > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-30 12:09 --- Created an attachment (id=21592) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21592&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451