[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #11 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 35995 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35995action=edit test case
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it --- (In reply to Salvatore Filippone from comment #11) Created attachment 35995 [details] test case Enjoy :) [sfilippo@jacobi tlink]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gnu/dev/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-dev/configure --prefix=/opt/gnu/dev --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc-dev/configure --prefix=/opt/gnu/dev --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc-dev/configure --prefix=/opt/gnu/dev --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog CC=gcc CXX=g++ --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 6.0.0 20150713 (experimental) (GCC) [sfilippo@jacobi tlink]$ gfortran -o testlk testlk.f90 /tmp/cchNLmkr.o: In function `__error_impl_mod_MOD_ser_error_print_stack': testlk.f90:(.text+0x1b): undefined reference to `__error_mod_MOD_serror' /tmp/cchNLmkr.o: In function `__error_impl_mod_MOD_par_error_print_stack': testlk.f90:(.text+0x3b): undefined reference to `__error_mod_MOD_perror' /tmp/cchNLmkr.o: In function `__error_mod_MOD_par_error_handler': testlk.f90:(.text+0x5f): undefined reference to `erractionrestore_' testlk.f90:(.text+0x7b): undefined reference to `__error_mod_MOD_perror' testlk.f90:(.text+0x97): undefined reference to `__error_mod_MOD_perror' /tmp/cchNLmkr.o: In function `__error_mod_MOD_ser_error_handler': testlk.f90:(.text+0xb8): undefined reference to `erractionrestore_' testlk.f90:(.text+0xc7): undefined reference to `__error_mod_MOD_serror' /tmp/cchNLmkr.o: In function `MAIN__': testlk.f90:(.text+0xfc): undefined reference to `__error_mod_MOD_serror' collect2: error: ld returned 1 exit status
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #13 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 35996 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35996action=edit test case Cleaned up a bit of noise due to the process of reducing the test case: it was spitting out a legitimate but pointless liker error about erractionrestore. [sfilippo@jacobi tlink]$ gfortran -o testlk testlk.f90 /tmp/ccbhv5VA.o: In function `__error_impl_mod_MOD_ser_error_print_stack': testlk.f90:(.text+0x1b): undefined reference to `__error_mod_MOD_serror' /tmp/ccbhv5VA.o: In function `__error_impl_mod_MOD_par_error_print_stack': testlk.f90:(.text+0x3b): undefined reference to `__error_mod_MOD_perror' /tmp/ccbhv5VA.o: In function `__error_mod_MOD_par_error_handler': testlk.f90:(.text+0x6a): undefined reference to `__error_mod_MOD_perror' testlk.f90:(.text+0x86): undefined reference to `__error_mod_MOD_perror' /tmp/ccbhv5VA.o: In function `__error_mod_MOD_ser_error_handler': testlk.f90:(.text+0xa5): undefined reference to `__error_mod_MOD_serror' /tmp/ccbhv5VA.o: In function `MAIN__': testlk.f90:(.text+0xda): undefined reference to `__error_mod_MOD_serror' collect2: error: ld returned 1 exit status
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it --- (In reply to Salvatore Filippone from comment #8) (In reply to Paul Thomas from comment #7) Salvatore Spoke too quickly: I get this linker error ppde3d.f90:(.text+0x9d0): undefined reference to `__psb_error_mod_MOD_psb_perror' ../../lib/libpsb_prec.a(psb_dilu_fct.o): In function `psb_dilu_fct_': psb_dilu_fct.f90:(.text+0x6a0): undefined reference to `__psb_error_mod_MOD_psb_serror' psb_dilu_fct.f90:(.text+0x21db): undefined reference to `__psb_error_mod_MOD_psb_serror' whereas the relevant implementation submodule shows: T __psb_error_impl_mod_MOD_psb_perror 0220 T __psb_error_impl_mod_MOD_psb_serror i.e. the name mangling is going wrong. Salvatore
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it --- (In reply to Paul Thomas from comment #7) Created attachment 35926 [details] A partially cooked patch to complete the implentation of submodules The attached is a first attempt to complete the submodule implementation such that private entities are correctly dealt with. There are two parts to the patch: (i) Modifications to the front end to write a second half to the module files, which contains all the information about the private entities in the module. This is the bulk of the patch; and (ii) A change in the way that declarations of private entities are handled in trans-decl.c. This follows a suggestion from Richard Biener to use a technique borrowed from g++. In this patch it is only applied to variables. Cheers Paul Seems to work for my codes. I am not completely happy with the fact that a change in the PRIVATE entities will cause a change of the .mod file; it may be argued that changes are more likely to occur in the submodules than in the main module, but still, this is not 100% satisfactory wrt the advertisement that submodules are ssolving the compilation cascade problem. From a user's point of view, I do not see a good solution to this; if the .mod file contains any kind of timestamp, it's going to change anyway, even in the case where the PRIVATE part is written to a separate file. On a relate note, the point raised in the mailing list about protecting trade secrets by putting them in the PRIVATE parts is IMHO moot: if I really wanted to protect trade secrets, I would put them in a separate module that is only ever USEd by the implementation files of the user visible module, files of which I only distribute the object code. I don't think that C++ is any different in this respect. Salvatore
[Bug tree-optimization/66280] [4.8/4.9 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1472
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66280 --- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 35763 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35763action=edit test case
[Bug tree-optimization/66280] [4.8/4.9 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1472
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66280 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot it --- Comment #11 from Salvatore Filippone sfilippone at uniroma2 dot it --- (In reply to Richard Biener from comment #9) Fixed on trunk sofar. I still see this (or a very similar) error from the Fortran front-end at r224364: [sfilippo@epsilon NewPSBLAS]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gnu/6.0.0/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/opt/gnu/6.0.0 --enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp --with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc --with-isl=/usr/local/travel/GNU/isl Thread model: posix gcc version 6.0.0 20150611 (experimental) (GCC) [sfilippo@epsilon NewPSBLAS]$ gfortran -O3 -c mv.f90 mv.f90:1:0: subroutine mv(m,n,nc,alpha,irp,ja,val, ^ internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1478 0xdbc689 vect_get_vec_def_for_operand(tree_node*, gimple_statement_base*, tree_node**) ../../gcc/gcc/tree-vect-stmts.c:1478 0xdc4ebc vectorizable_store ../../gcc/gcc/tree-vect-stmts.c:5330 0xdcfba6 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ../../gcc/gcc/tree-vect-stmts.c:7496 0xde90d5 vect_schedule_slp_instance ../../gcc/gcc/tree-vect-slp.c:3481 0xde96c6 vect_schedule_slp(_loop_vec_info*, _bb_vec_info*) ../../gcc/gcc/tree-vect-slp.c:3551 0xdd4bf7 vect_transform_loop(_loop_vec_info*) ../../gcc/gcc/tree-vect-loop.c:6218 0xdef242 vectorize_loops() ../../gcc/gcc/tree-vectorizer.c:495 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Salvatore
[Bug tree-optimization/42108] [4.8/4.9/5 Regression] 50% performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 --- Comment #66 from Salvatore Filippone sfilippone at uniroma2 dot it --- As far as I remember(In reply to rguent...@suse.de from comment #65) On Wed, 10 Dec 2014, burnus at gcc dot gnu.org wrote: Fortran 66 compilers did. For instance, DO i = 2, 1 would then be executed once. (Such loops are not permitted in F66 - and some compilers executed them once others zero times; since F77, such loops are permitted and executed zero times. Unsurprisingly, some old code from the 60s relies on the execute once feature.) g77 and some commercial compilers have a compile flag like -f66, gfortran hasn't and I don't think it ever will.] I wondered if DO i = 1, 1, 0 is valid (a step of zero). Note that DO i = 2, 1 wouldn't be executed once with the current generated code, only DO i = 1, 1 is, but with step == 0 it would divide by zero. Step 0 is not allowed (see e.g. F2003 Handbook, sect. 8.7.2.1.1). Salvatore
[Bug fortran/63733] New: [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 Bug ID: 63733 Summary: [OOP] wrong resolution for OPERATOR generics Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 33881 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33881action=edit test case Hi, The attached test case, slightly modified from an original by Alberto F. Martin-Huertas in https://gcc.gnu.org/ml/fortran/2014-10/msg00124.html, changes behaviour across versions; in particular, 4.7.3 seems correct and all other versions I tried are not. According to Steve Lionel https://software.intel.com/en-us/forums/topic/534799 the current Intel and gfortran behaviour is wrong, and this is also my impression. We have not had a definite answer at https://groups.google.com/forum/#!topic/comp.lang.fortran/aFNK3FXqTUA Again, my reading of the standard is that 4.7.3 is correct and the others are wrong, but of course I will gladly accept a correction; either way, at least one version of gfortran is wrong. -- [sfilippo@jacobi F2003]$ module switch gnu gnu/4.6.4 gnu/4.6.4 - loads the GNU 4.6.4 compilers suite Version 4.6.4 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/4.7.3 gnu/4.7.3 - loads the GNU 4.7.3 compilers suite Version 4.7.3 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_child sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/4.8.3 gnu/4.8.3 - loads the GNU 4.8.3 compilers suite Version 4.8.3 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/4.9.1 gnu/4.9.1 - loads the GNU 4.9.1 compilers suite Version 4.9.1 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$ module switch gnu gnu/5.0.0 gnu/5.0.0 - loads the GNU 5.0.0-pre compilers suite Version 5.0.0 [sfilippo@jacobi F2003]$ gfortran -o test_ov test_ov.f90 [sfilippo@jacobi F2003]$ ./test_ov sum_parent sum_parent sum_child [sfilippo@jacobi F2003]$
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added Attachment #33127|0 |1 is obsolete|| --- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 33129 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33129action=edit test case Reduced test case, giving: [sfilippo@jacobi leak-demo]$ gfortran -c foo-test-ice.f90 foo-test-ice.f90: In function ‘__final_foo_vector_field_mod_Vector_field’: foo-test-ice.f90:62:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:146 end module foo_vector_field_mod ^ 0x602fc5 gfc_conv_descriptor_data_get(tree_node*) ../../gcc/gcc/fortran/trans-array.c:146 0x60a24e gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*) ../../gcc/gcc/fortran/trans-array.c:5350 0x674bea gfc_trans_deallocate(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:5484 0x5ff2b7 trans_code ../../gcc/gcc/fortran/trans.c:1798 0x66a583 gfc_trans_if_1 ../../gcc/gcc/fortran/trans-stmt.c:989 0x670dea gfc_trans_if(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:1020 0x5ff3a7 trans_code ../../gcc/gcc/fortran/trans.c:1736 0x672114 gfc_trans_simple_do ../../gcc/gcc/fortran/trans-stmt.c:1446 0x672114 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/gcc/fortran/trans-stmt.c:1609 0x5ff37a trans_code ../../gcc/gcc/fortran/trans.c:1748 0x62966b gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5765 0x600d61 gfc_generate_module_code(gfc_namespace*) ../../gcc/gcc/fortran/trans.c:1995 0x5bc031 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4934 0x5bc031 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:5144 0x5fa935 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [sfilippo@jacobi leak-demo]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.10/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu/4.10 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog Thread model: posix gcc version 4.10.0 20140716 (experimental) (GCC) [sfilippo@jacobi leak-demo]$
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #5 from Salvatore Filippone sfilippone at uniroma2 dot it --- Code works with 4.8.3, so this is a regression.
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it --- The original code leaks memory like a sieve, and looks suspiciously similar to PR55603. It is just possible that the whole area of function results needs to be reviewed (I guess that would be no small task) Salvatore
[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 --- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it --- Looking at the original code of PR 61819, it is quite possible that the real culprit are CLASS() ALLOCATABLE components, not necessarily the result itself (being allocatable). Salvatore
[Bug fortran/61830] New: Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 Bug ID: 61830 Summary: Memory leak with assignment to array of derived types with allocatable components Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 33132 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33132action=edit test case Hi, The attached code shows the problem. When I started investigating I was using 4.10 but I ran into PR61819 while reducing the test case. With 4.8.3 I get the following: [sfilippo@jacobi runs]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.8.3/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.3/configure --prefix=/usr/local/gnu/4.8.3 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.8.3 (GCC) [sfilippo@jacobi runs]$ valgrind --leak-check=full ./foo-test-leak ==20638== Memcheck, a memory error detector ==20638== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==20638== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==20638== Command: ./foo-test-leak ==20638== Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component ==20638== ==20638== HEAP SUMMARY: ==20638== in use at exit: 6,164 bytes in 23 blocks ==20638== total heap usage: 89 allocs, 66 frees, 35,518 bytes allocated ==20638== ==20638== 560 (48 direct, 512 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 5 ==20638==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==20638==by 0x400B70: __foo_base_mod_MOD_foo_geall (foo-test-leak.f90:96) ==20638==by 0x401F8B: __foo_scalar_field_mod_MOD_new_scalar_field (foo-test-leak.f90:141) ==20638==by 0x40271F: __foo_vector_field_mod_MOD_new_vector_field (foo-test-leak.f90:163) ==20638==by 0x402AC8: MAIN__ (foo-test-leak.f90:188) ==20638==by 0x4031D3: main (foo-test-leak.f90:179) ==20638== ==20638== 5,600 (480 direct, 5,120 indirect) bytes in 10 blocks are definitely lost in loss record 5 of 5 ==20638==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==20638==by 0x400B70: __foo_base_mod_MOD_foo_geall (foo-test-leak.f90:96) ==20638==by 0x401F8B: __foo_scalar_field_mod_MOD_new_scalar_field (foo-test-leak.f90:141) ==20638==by 0x40271F: __foo_vector_field_mod_MOD_new_vector_field (foo-test-leak.f90:163) ==20638==by 0x402C9E: MAIN__ (foo-test-leak.f90:192) ==20638==by 0x4031D3: main (foo-test-leak.f90:179) ==20638== ==20638== LEAK SUMMARY: ==20638==definitely lost: 528 bytes in 11 blocks ==20638==indirectly lost: 5,632 bytes in 11 blocks ==20638== possibly lost: 0 bytes in 0 blocks ==20638==still reachable: 4 bytes in 1 blocks ==20638== suppressed: 0 bytes in 0 blocks ==20638== Reachable blocks (those to which a pointer was found) are not shown. ==20638== To see them, rerun with: --leak-check=full --show-reachable=yes ==20638== ==20638== For counts of detected and suppressed errors, rerun with: -v ==20638== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6) --- If I change line 163 this%u = [new_scalar_field()] into do i=1, size(this%u) associate(sf=this%u(i)) sf = new_scalar_field() end associate end do then I get no leak [sfilippo@jacobi runs]$ valgrind --leak-check=full ./foo-test-leak-fixed ==20852== Memcheck, a memory error detector ==20852== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==20852== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==20852== Command: ./foo-test-leak-fixed ==20852== Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class() component Scalar deallocation Deallocate class
[Bug fortran/61830] Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 33133 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33133action=edit workaround
[Bug fortran/61819] New: ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Bug ID: 61819 Summary: ICE in gfc_conv_descriptor_data_get Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it The attached code produces the ICE in both trunk and 4.9.0. The code is from a test case I was trying to reduce while investigating a memory leak, so something fishy is going on. -- trunk --- [sfilippo@jacobi leak-demo]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.10/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu/4.10 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu/4.10 --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.10.0 20140708 (experimental) (GCC) [sfilippo@jacobi leak-demo]$ gfortran -O0 -ggdb -o foo-test foo-test.f90 foo-test.f90: In function ‘__final_foo_vector_field_mod_Vector_field’: foo-test.f90:196:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:146 end module foo_vector_field_mod ^ 0x602855 gfc_conv_descriptor_data_get(tree_node*) ../../gcc/gcc/fortran/trans-array.c:146 0x609a5e gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*) ../../gcc/gcc/fortran/trans-array.c:5346 0x672bda gfc_trans_deallocate(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:5484 0x5feb47 trans_code ../../gcc/gcc/fortran/trans.c:1798 0x668553 gfc_trans_if_1 ../../gcc/gcc/fortran/trans-stmt.c:989 0x66edda gfc_trans_if(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:1020 0x5fec37 trans_code ../../gcc/gcc/fortran/trans.c:1736 0x670104 gfc_trans_simple_do ../../gcc/gcc/fortran/trans-stmt.c:1446 0x670104 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/gcc/fortran/trans-stmt.c:1609 0x5fec0a trans_code ../../gcc/gcc/fortran/trans.c:1748 0x628cdb gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5734 0x6005f1 gfc_generate_module_code(gfc_namespace*) ../../gcc/gcc/fortran/trans.c:1995 0x5bb861 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4934 0x5bb861 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:5144 0x5fa195 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. --- 4.9--- [sfilippo@jacobi leak-demo]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.0/configure --prefix=/usr/local/gnu/4.9.0 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.9.0 (GCC) [sfilippo@jacobi leak-demo]$ gfortran -O0 -ggdb -o foo-test foo-test.f90 foo-test.f90: In function ‘__final_foo_vector_field_mod_Vector_field’: foo-test.f90:196:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145 end module foo_vector_field_mod ^ 0x5e2348 gfc_conv_descriptor_data_get(tree_node*) ../../gcc-4.9.0/gcc/fortran/trans-array.c:145 0x5e7e3f gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*) ../../gcc-4.9.0/gcc/fortran/trans-array.c:5346 0x62f7ca gfc_trans_deallocate(gfc_code*) ../../gcc-4.9.0/gcc/fortran/trans-stmt.c:5478 0x5df257 trans_code ../../gcc-4.9.0/gcc/fortran/trans.c:1798 0x626623 gfc_trans_if_1 ../../gcc-4.9.0/gcc/fortran/trans-stmt.c:986 0x62c3aa gfc_trans_if(gfc_code*) ../../gcc-4.9.0/gcc/fortran/trans-stmt.c:1017 0x5df347 trans_code ../../gcc-4.9.0/gcc/fortran/trans.c:1736 0x62d4a1 gfc_trans_simple_do ../../gcc-4.9.0/gcc/fortran/trans-stmt.c:1440 0x62d4a1 gfc_trans_do(gfc_code*, tree_node*) ../../gcc-4.9.0/gcc/fortran/trans-stmt.c:1603 0x5df31a trans_code ../../gcc-4.9.0/gcc/fortran/trans.c:1748 0x5fe6bb gfc_generate_function_code(gfc_namespace*) ../../gcc-4.9.0/gcc/fortran/trans-decl.c:5610 0x5e06e1
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it --- Created attachment 33127 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33127action=edit test case
[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it --- Same ICE with a fresh trunk as of today.
[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added Summary|[4.10 regression] Memory |[4.9/4.10 regression] |leak with INTENT(OUT) CLASS |Memory leak with |argument w/ allocatable |INTENT(OUT) CLASS argument |CLASS components|w/ allocatable CLASS ||components --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it --- Yup, it is a regression in 4.9.0 as well. [sfilippo@epsilon IMAGING]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gnu/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.0/configure --prefix=/opt/gnu/4.9.0 --enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp --with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc --with-cloog=/usr/local/travel/GNU/cloog Thread model: posix gcc version 4.9.0 (GCC) [sfilippo@epsilon IMAGING]$ gfortran -o test_leak_490 -O3 test_leak.f90 [sfilippo@epsilon IMAGING]$ valgrind ./test_leak_490 ==4473== Memcheck, a memory error detector ==4473== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==4473== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==4473== Command: ./test_leak_490 ==4473== Iteration1 Iteration2 ==4473== ==4473== HEAP SUMMARY: ==4473== in use at exit: 6,291,552 bytes in 5 blocks ==4473== total heap usage: 32 allocs, 27 frees, 10,497,741 bytes allocated ==4473== ==4473== LEAK SUMMARY: ==4473==definitely lost: 48 bytes in 1 blocks ==4473==indirectly lost: 2,097,152 bytes in 1 blocks ==4473== possibly lost: 0 bytes in 0 blocks ==4473==still reachable: 4,194,352 bytes in 3 blocks ==4473== suppressed: 0 bytes in 0 blocks ==4473== Rerun with --leak-check=full to see details of leaked memory ==4473== ==4473== For counts of detected and suppressed errors, rerun with: -v ==4473== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[Bug fortran/60922] New: [4.9 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 Bug ID: 60922 Summary: [4.9 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 32653 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32653action=edit test case Attached code runs fine with 4.8.2, but generates a memory leak with current trunk, unless I explicitly add FINAL subroutines, which should not be necessary for this simple case. Possibly 4.9.0 is affected as well. Symptoms similar to PR 47637. fails with trunk --- [sfilippo@epsilon IMAGING]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gnu/4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/opt/gnu/4.9 --enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp --with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc --with-cloog=/usr/local/travel/GNU/cloog : (reconfigured) ../gcc/configure --prefix=/opt/gnu/4.9 --with-gmp=/usr/local/travel/GNU/gmp --with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc --with-cloog=/usr/local/travel/GNU/cloog --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.10.0 20140422 (experimental) (GCC) [sfilippo@epsilon IMAGING]$ gfortran -o test_leak_410 -O3 test_leak.f90 [sfilippo@epsilon IMAGING]$ valgrind ./test_leak_410 ==2140== Memcheck, a memory error detector ==2140== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==2140== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==2140== Command: ./test_leak_410 ==2140== Iteration1 Iteration2 ==2140== ==2140== HEAP SUMMARY: ==2140== in use at exit: 6,291,552 bytes in 5 blocks ==2140== total heap usage: 32 allocs, 27 frees, 10,497,741 bytes allocated ==2140== ==2140== LEAK SUMMARY: ==2140==definitely lost: 48 bytes in 1 blocks ==2140==indirectly lost: 2,097,152 bytes in 1 blocks ==2140== possibly lost: 0 bytes in 0 blocks ==2140==still reachable: 4,194,352 bytes in 3 blocks ==2140== suppressed: 0 bytes in 0 blocks ==2140== Rerun with --leak-check=full to see details of leaked memory ==2140== ==2140== For counts of detected and suppressed errors, rerun with: -v ==2140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) Works with 4.8.2--- [sfilippo@epsilon IMAGING]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gnu/4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.2/configure --prefix=/opt/gnu/4.8.2 --enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp --with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc --with-cloog=/usr/local/travel/GNU/cloog Thread model: posix gcc version 4.8.2 (GCC) [sfilippo@epsilon IMAGING]$ gfortran -o test_leak_482 -O3 test_leak.f90 [sfilippo@epsilon IMAGING]$ valgrind ./test_leak_482 ==2122== Memcheck, a memory error detector ==2122== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==2122== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==2122== Command: ./test_leak_482 ==2122== Iteration1 Iteration2 ==2122== ==2122== HEAP SUMMARY: ==2122== in use at exit: 4,194,352 bytes in 3 blocks ==2122== total heap usage: 28 allocs, 25 frees, 10,497,699 bytes allocated ==2122== ==2122== LEAK SUMMARY: ==2122==definitely lost: 0 bytes in 0 blocks ==2122==indirectly lost: 0 bytes in 0 blocks ==2122== possibly lost: 0 bytes in 0 blocks ==2122==still reachable: 4,194,352 bytes in 3 blocks ==2122== suppressed: 0 bytes in 0 blocks ==2122== Rerun with --leak-check=full to see details of leaked memory ==2122== ==2122== For counts of detected and suppressed errors, rerun with: -v ==2122== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[Bug fortran/59662] New: [OOP] TBP subroutine call rejected in contained subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662 Bug ID: 59662 Summary: [OOP] TBP subroutine call rejected in contained subroutine Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 31565 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31565action=edit testcase The attached code fails with current trunk with what appears to be an overzealous check. The code compiles and works fine with 4.8.1. Commenting the BIND(C) routine call or moving the foobar subroutine outside of foo masks the problem. --- [sfilippo@jacobi bug36]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu/4.9 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu/4.9 --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu/4.9 --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.9.0 20140102 (experimental) (GCC) [sfilippo@jacobi bug36]$ gfortran -c testcase.f90 testcase.f90:59.22: call a%mv_to(acsc) 1 Error: 'mv_to_base' at (1) is not a function
[Bug fortran/57556] New: [OOP][Regression] ICE with move_alloc on polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57556 Bug ID: 57556 Summary: [OOP][Regression] ICE with move_alloc on polymorphic component Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 30274 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30274action=edit Test case The attached code generates the ICE when compiled with -fcheck=all. Looks very similar but independent of PR57542, since the patch for the latter was already applied. Works with 4.7/4.8. [sfilippo@jacobi BugDeallocateFinal]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog Thread model: posix gcc version 4.9.0 20130606 (experimental) (GCC) [sfilippo@jacobi BugDeallocateFinal]$ gfortran -c testMoveAlloc.f90 [sfilippo@jacobi BugDeallocateFinal]$ gfortran -c -fcheck=all testMoveAlloc.f90 testMoveAlloc.f90: In function 'realloc_pool': testMoveAlloc.f90:31:0: internal compiler error: tree check: did not expect class 'type', have 'type' (boolean_type) in append_to_statement_list, at tree-iterator.c:94 call move_alloc(pool(i)%item,dbp(i)%item) ^ 0xb57be9 tree_not_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../gcc/gcc/tree.c:9159 0x9d9a0c non_type_check ../../gcc/gcc/tree.h:3869 0x9d9a0c append_to_statement_list(tree_node*, tree_node**) ../../gcc/gcc/tree-iterator.c:94 0x5b6f32 add_expr_to_chain ../../gcc/gcc/fortran/trans.c:1402 0x5b8ec6 gfc_add_block_to_block(stmtblock_t*, stmtblock_t*) ../../gcc/gcc/fortran/trans.c:1448 0x5b909b gfc_build_final_call ../../gcc/gcc/fortran/trans.c:898 0x5b909b gfc_add_finalizer_call(stmtblock_t*, gfc_expr*) ../../gcc/gcc/fortran/trans.c:1016 0x5b9aee gfc_deallocate_scalar_with_status(tree_node*, tree_node*, bool, gfc_expr*, gfc_typespec) ../../gcc/gcc/fortran/trans.c:1300 0x6038ec conv_intrinsic_move_alloc ../../gcc/gcc/fortran/trans-intrinsic.c:7592 0x6038ec gfc_conv_intrinsic_subroutine(gfc_code*) ../../gcc/gcc/fortran/trans-intrinsic.c:7790 0x5b8bd2 trans_code ../../gcc/gcc/fortran/trans.c:1594 0x619544 gfc_trans_simple_do ../../gcc/gcc/fortran/trans-stmt.c:1425 0x619544 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/gcc/fortran/trans-stmt.c:1588 0x5b8b0a trans_code ../../gcc/gcc/fortran/trans.c:1635 0x5e0cce gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5460 0x5b9fd1 gfc_generate_module_code(gfc_namespace*) ../../gcc/gcc/fortran/trans.c:1859 0x578677../../gcc/gcc/fortran/parse.c:4496 0x578677 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4706 0x5b47f5 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [sfilippo@jacobi BugDeallocateFinal]$ translate_all_program_units
[Bug fortran/57542] New: [OOP, Fortran] ICE on FINALization with specific options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57542 Bug ID: 57542 Summary: [OOP, Fortran] ICE on FINALization with specific options Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 30267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30267action=edit Test case The attached code triggers an ICE with debug options -O0 -ggdb -fcheck=all log --- [sfilippo@jacobi BugDeallocateFinal]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog Thread model: posix gcc version 4.9.0 20130605 (experimental) (GCC) [sfilippo@jacobi BugDeallocateFinal]$ gfortran -c -O3 testFinal.f90 [sfilippo@jacobi BugDeallocateFinal]$ gfortran -c -O0 -ggdb -fcheck=all testFinal.f90 testFinal.f90: In function 'testfinal': testFinal.f90:24:0: internal compiler error: in gfc_build_final_call, at fortran/trans.c:898 deallocate(var%v(1)%item%item) ^ 0x5b97d1 gfc_build_final_call ../../gcc/gcc/fortran/trans.c:898 0x5b97d1 gfc_add_finalizer_call(stmtblock_t*, gfc_expr*) ../../gcc/gcc/fortran/trans.c:1014 0x5b9aee gfc_deallocate_scalar_with_status(tree_node*, tree_node*, bool, gfc_expr*, gfc_typespec) ../../gcc/gcc/fortran/trans.c:1298 0x61c174 gfc_trans_deallocate(gfc_code*) ../../gcc/gcc/fortran/trans-stmt.c:5429 0x5b8a47 trans_code ../../gcc/gcc/fortran/trans.c:1683 0x5e0cce gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5460 0x5788f8 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4509 0x5788f8 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4706 0x5b47f5 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [sfilippo@jacobi BugDeallocateFinal]$
[Bug fortran/56969] New: ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 Bug #: 56969 Summary: ISO_C_BINDING regression with current trunk Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 29876 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29876 test case Hi, Attached code works with 4.8, fails with trunk. Salvatore - [sfilippo@jacobi BugCBind]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.0/configure --prefix=/usr/local/gnu48 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.8.0 (GCC) [sfilippo@jacobi BugCBind]$ gfortran -c tst_cbind.f90 [sfilippo@jacobi BugCBind]$ [sfilippo@jacobi BugCBind]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.9.0 20130411 (experimental) (GCC) [sfilippo@jacobi BugCBind]$ gfortran -c tst_cbind.f90 tst_cbind.f90:57.18: if (c_associated(a%deviceMat%Mat)) then 1 Error: Name 'c_associated' at (1) is an ambiguous reference to 'c_associated' from module '__iso_c_binding' tst_cbind.f90:59.5: end if 1 Error: Expecting END SUBROUTINE statement at (1) [sfilippo@jacobi BugCBind]$
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #18 from Salvatore Filippone sfilippone at uniroma2 dot it 2013-04-05 09:32:25 UTC --- (In reply to comment #17) Hi, I am seeing intermittent issues with CLASS,ALLOCATABLE,INTENT(OUT) variables that have a CLASS,ALLOCATABLE component; however when I tried to reduce to the following test code, it segfaults on the inner clone, whereas the full code only fails on the outer code. In any case, the attached code is supposed to work, and it fails (under 4.7.2, 4.8.0 and trunk) === module base_inner type inner integer, allocatable :: iv(:) contains procedure, pass(val) :: clone = inner_clone end type inner contains subroutine inner_clone(val,res) class(inner) :: val class(inner), allocatable, intent(out) :: res allocate(inner :: res) res%iv = val%iv end subroutine inner_clone end module base_inner module base_outer use base_inner type outer class(inner), allocatable :: inn contains procedure, pass(val) :: clone = outer_clone end type outer contains subroutine outer_clone(val,res) class(outer) :: val class(outer), allocatable, intent(out) :: res allocate(outer :: res) call val%inn%clone(res%inn) end subroutine outer_clone end module base_outer program testclass use base_outer class(inner), allocatable :: inner1, inner2 class(outer), allocatable :: outer1, outer2 allocate(inner :: inner1) allocate(inner1%iv(3)) call inner1%clone(inner2) write(0,*) allocated(inner1),allocated(inner2) allocate(outer :: outer1) allocate(inner :: outer1%inn) allocate(outer1%inn%iv(3)) call outer1%clone(outer2) write(0,*) allocated(outer1),allocated(outer2) end program testclass
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #19 from Salvatore Filippone sfilippone at uniroma2 dot it 2013-04-05 09:33:18 UTC --- (In reply to comment #17) Hi, I am seeing intermittent issues with CLASS,ALLOCATABLE,INTENT(OUT) variables that have a CLASS,ALLOCATABLE component; however when I tried to reduce to the following test code, it segfaults on the inner clone, whereas the full code only fails on the outer code. In any case, the attached code is supposed to work, and it fails (under 4.7.2, 4.8.0 and trunk) === module base_inner type inner integer, allocatable :: iv(:) contains procedure, pass(val) :: clone = inner_clone end type inner contains subroutine inner_clone(val,res) class(inner) :: val class(inner), allocatable, intent(out) :: res allocate(inner :: res) res%iv = val%iv end subroutine inner_clone end module base_inner module base_outer use base_inner type outer class(inner), allocatable :: inn contains procedure, pass(val) :: clone = outer_clone end type outer contains subroutine outer_clone(val,res) class(outer) :: val class(outer), allocatable, intent(out) :: res allocate(outer :: res) call val%inn%clone(res%inn) end subroutine outer_clone end module base_outer program testclass use base_outer class(inner), allocatable :: inner1, inner2 class(outer), allocatable :: outer1, outer2 allocate(inner :: inner1) allocate(inner1%iv(3)) call inner1%clone(inner2) write(0,*) allocated(inner1),allocated(inner2) allocate(outer :: outer1) allocate(inner :: outer1%inn) allocate(outer1%inn%iv(3)) call outer1%clone(outer2) write(0,*) allocated(outer1),allocated(outer2) end program testclass
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #21 from Salvatore Filippone sfilippone at uniroma2 dot it 2013-04-05 12:29:11 UTC --- (In reply to comment #20) (In reply to comment #18) I am seeing intermittent issues with CLASS,ALLOCATABLE,INTENT(OUT) variables that have a CLASS,ALLOCATABLE component; however when I tried to reduce to the following test code, it segfaults on the inner clone, whereas the full code only fails on the outer code. In any case, the attached code is supposed to work, and it fails (under 4.7.2, 4.8.0 and trunk) For the code in comment 18 and comment 19, I get the output T T T T using the latest draft patch at https://userpage.physik.fu-berlin.de/~tburnus/final/ (It doesn't help with comment 3.) Thus, if you build GCC yourself, that might be a work around. Thanks for the heads up. After further reflection, I've come to realize that for what I want to do, I can use INTENT(OUT) only when FINAL works. So, from now on I can fork a code with INTENT(OUT) and test your patch, but the main stable code will have to do with INTENT(INOUT) until FINAL is fully tested. Thanks a lot
[Bug fortran/55593] New: Bogus error on passing DO LOOP variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55593 Bug #: 55593 Summary: Bogus error on passing DO LOOP variable Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it CC: tkoe...@gcc.gnu.org Created attachment 28877 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28877 test case Hi, I get the following bogus error: === [sfilippo@localhost bug34]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu48 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu48 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu48 --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.8.0 20121204 (experimental) (GCC) [sfilippo@localhost bug34]$ gfortran -c bug34.f90 bug34.f90:95.21: call loc_to_glob(i,idx,desc_a,info) 1 bug34.f90:94.14: do i=1, nrow 2 Error: Variable 'i' at (1) not definable inside loop beginning at (2) as INTENT(INOUT) argument to subroutine 'loc_to_glob' === The error is bogus because the proper specific subroutine should be loc_to_glob2s and it gets I as the actual argument corresponding to an INTENT(IN) dummy (x). The compiler appears to be confused by the generic name being the same as one of the specifics; indeed, if I change the second specific name to loc_to_glob1v on line 49, the error goes away. Note that having one of the specific names the same as the generic is allowed by the standard. (even though it's not a very good idea, and I'll probably change it anyway) This sure looks like having been caused by the fix for PR30146.
[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #14 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-10 11:36:45 UTC --- (In reply to comment #13) Salvatore, I would say we can close this PR (as a duplicate of PR54784), unless the runtime error with 4.6 on darwin is a regression (which I currently can not check). Fine with me. I presume it should make its way into 4.7.3, right? Thanks Salvatore
[Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 Bug #: 54874 Summary: OOP: polymorphic allocation with SOURCE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 28396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28396 test case Hi, I am getting the following output from the test case. It seems wrong, I do not see why allocating the polymorphic component in p%vect(4) should change the entries p%vect(1:3) This may or may not be a duplicate of 54784. [sfilippo@jacobi bug34]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.7.2 (GCC) [sfilippo@jacobi bug34]$ gfortran -o testpolyvect testpolyvect.f90 [sfilippo@jacobi bug34]$ ./testpolyvect level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 Base inner descr level2 Base inner descr level3 Base inner descr level4 Base inner descr
[Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 --- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 09:59:28 UTC --- Just opened 54874. May or may not be a duplicate of this one.
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 10:02:41 UTC --- Interestingly, taking out the outer container p% makes the code work... --- [sfilippo@jacobi bug34]$ gfortran -o poywork polywork.f90 [sfilippo@jacobi bug34]$ ./poywork level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level4 Base inner descr -- program testsource use testmod type(level), allocatable :: vect(:) class(outer), allocatable :: outvar1, outvar2 integer :: i,j,k,n,info n = 4 allocate(outer :: outvar1) allocate(outer :: outvar2) allocate(new_inner :: outvar1%var) allocate(inner :: outvar2%var) allocate(vect(n)) do i=1, n if (in) then allocate(vect(i)%outvar,source=outvar1) else allocate(vect(i)%outvar,source=outvar2) end if write(0,*) do k=1,i write(0,*) 'level ',k call vect(k)%outvar%var%descr() end do end do end program testsourc
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 10:37:13 UTC --- And it is also a regression, as it works on 4.6.3: --- [sfilippo@jacobi bug34]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6.3/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.6.3 (GCC) [sfilippo@jacobi bug34]$ gfortran -o testpolyvect testpolyvect.f90 [sfilippo@jacobi bug34]$ ./testpolyvect level1 New inner descr level1 New inner descr level2 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level1 New inner descr level2 New inner descr level3 New inner descr level4 Base inner descr
[Bug fortran/54874] OOP: polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 11:03:10 UTC --- (In reply to comment #3) And it is also a regression, as it works on 4.6.3: ... Well, this may be more complicated. On x86_64-apple-darwin10, compiling the attached test with 4.6.3 gives: Something is very fishy here..
[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 14:46:15 UTC --- (In reply to comment #5) (In reply to comment #0) I am getting the following output from the test case. It seems wrong, I do not see why allocating the polymorphic component in p%vect(4) should change the entries p%vect(1:3) This may or may not be a duplicate of 54784. Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that the patch given there also fixes the behavior here. Great news! Thanks Salvatore
[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54874 --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-09 16:02:35 UTC --- (In reply to comment #6) (In reply to comment #5) (In reply to comment #0) I am getting the following output from the test case. It seems wrong, I do not see why allocating the polymorphic component in p%vect(4) should change the entries p%vect(1:3) This may or may not be a duplicate of 54784. Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that the patch given there also fixes the behavior here. Great news! Thanks Salvatore I can confirm that patching my 4.7.2 source tree fixes not just the test case but also the code it was derived from, on x86_64-linux.
[Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-08 16:22:42 UTC --- Hello, I have a different problem that is definitely related to this area, but may or may not be the same. I have (as usual :) a complex nesting of polymorphic derived types, and I have a need to handle reallocation and re-population of a vector of such containers. The type hierarchy is something like this type mld_d_base_solver_type end type type mld_d_base_smoother_type class(mld_d_base_solver_type), allocatable :: sv end type mld_d_onelev_type class(mld_d_base_smoother_type), allocatable :: sm end type type, extends(psb_dprec_type) :: mld_dprec_type type(mld_d_onelev_type), allocatable :: precv(:) end type Consider the following snippet of code: deallocate(p%precv,stat=info) if (info == 0) allocate(p%precv(newsz),stat=info) if (info /= 0) then info = -1 return end if do i=1, newsz if (info == 0) then if (i ==1) then allocate(p%precv(i)%sm,source=base_sm,stat=info) else if (i newsz) then allocate(p%precv(i)%sm,source=med_sm,stat=info) else allocate(p%precv(i)%sm,source=coarse_sm,stat=info) end if end if if (info /= 0) then info = -1 return end if write(0,*) 'Copy back at level',i do k=1,i write(0,*) ' level',k call p%precv(k)%sm%sv%descr(info,iout=0) if (info /= 0) return end do end do You would expect the allocate with source at I=4 to leave untouched the elements of p%precv(1:3), and yet this is the output I get with 4.7.2: Copy back at level 1 level 1 TLU: test a new solver kind Copy back at level 2 level 1 TLU: test a new solver kind level 2 TLU: test a new solver kind Copy back at level 3 level 1 TLU: test a new solver kind level 2 TLU: test a new solver kind level 3 TLU: test a new solver kind Copy back at level 4 level 1 Incomplete factorization solver: ILU(n) Fill level: 0 level 2 Incomplete factorization solver: ILU(n) Fill level: 0 level 3 Incomplete factorization solver: ILU(n) Fill level: 0 level 4 Incomplete factorization solver: ILU(n) Fill level: 0 Intermediate at level 1 Incomplete factorization solver: ILU(n) Fill level: 0 - This clearly does not make sense. I can send Janus the full code to reproduce the error. Does it seem related? Thanks Salvatore
[Bug fortran/46321] [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321 --- Comment #5 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-05-07 09:32:30 UTC --- (In reply to comment #1) Note: There are four cases where a polymorphic deallocate is needed - though some might end up in the same code path: - explicit DEALLOCATE (cf. comment 0) - implicit deallocate at the end of the scope - implicit deallocate via INTENT(OUT) (cf. PR 47637) - implicit deallocate when doing polymorphic reallocate on assignment (PR 43366) Looks to me like work on FINAL needs to be interfaced here anyway. Naive view is that $free points to a FINAL if there is one, or to a default when there's no FINAL, but the hookup work is the same..
[Bug fortran/38813] ICE with C_LOC(array)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-01-13 12:44:46 UTC --- Hello, Has this ever been resolved? I still get an ICE with a code that is essentially that of comment 1, i.e. getting the C_LOC of an allocatable component; this is true of 4.6.1 and of current trunk as of today. Interestingly, the following compiles (but I have not tried yet if it works at runtime): module foo_mod type foo_type integer, allocatable :: idx(:) end type foo_type end module foo_mod subroutine bar2(data) use foo_mod use iso_c_binding implicit none type(foo_type), intent(inout), target :: data type(c_ptr) :: cptr call getcptr(cptr,data%idx) contains subroutine getcptr(cp,v) type(c_ptr) :: cp integer, allocatable, target :: v(:) cp = c_loc(v) end subroutine getcptr end subroutine bar2 Thanks a lot Salvatore
[Bug fortran/38813] ICE with C_LOC(array)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813 --- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-01-13 12:48:13 UTC --- (In reply to comment #6) And the example that still fails: -- module foo_mod type foo_type integer, allocatable :: idx(:) end type foo_type end module foo_mod subroutine bar(data) use foo_mod use iso_c_binding implicit none type(foo_type), intent(inout), target :: data type(c_ptr) :: cptr cptr = c_loc(data%idx) end subroutine bar -- [sfilippo@donald bug32]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.7.0 20120110 (experimental) (GCC) [sfilippo@donald bug32]$ gfortran -c bar.f90 bar.f90: In function 'bar': bar.f90:14:0: internal compiler error: Errore di segmentazione Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #23 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-12-03 12:00:43 UTC --- Yes, TYPE FROM and polymorphic TO is exactly the typical usage I have (indeed, it also was the original test case) Thanks
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-09-14 13:46:00 UTC --- (In reply to comment #8) The test case in my original post is wrong in this respect I mean: in the original post for pr41656.
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-09-14 13:45:13 UTC --- Duh! My bad: all versions of scal are supposed to update the A dummy argument, which should be INTENT(INOUT). The test case in my original post is wrong in this respect :( Salvatore
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-09-14 15:02:46 UTC --- (In reply to comment #11) relieved if Salvatore could tell us that his latest code still compiles with gfortran ... Cheers, Janus Yes it does. No (new) worries here Salvatore
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #15 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-05-30 09:11:08 UTC --- (In reply to comment #13) Moreover, I think that this test case is in fact invalid, cf. PR 48887. Hm. I see; I wonder, is this something that was added in F2008 or was it present in F2003?
[Bug fortran/48699] New: [OOP] MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 Summary: [OOP] MOVE_ALLOC of polymorphic variables Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 24056 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24056 test-case Hello, The attached examples fail in rather strange ways, on both current trunk and 4.6.0. -- [sfilippo@donald bug31]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.7.0 20110418 (experimental) (GCC) [sfilippo@donald bug31]$ gfortran -o testmv1 testmv1.f90 /tmp/ccIl5I0L.o:(.data+0x58): undefined reference to `__copy_foo2_Bar2.1685' collect2: ld returned 1 exit status [sfilippo@donald bug31]$ gfortran -c testmv2.f90 testmv2.f90:38.20: call move_alloc(sm,dat%sm) 1 Error: 'from' argument of 'move_alloc' intrinsic at (1) must be ALLOCATABLE The symptoms seem to be about two different things, though.
[Bug fortran/48699] [OOP] MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-04-20 12:07:04 UTC --- Created attachment 24057 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24057 test-case
[Bug fortran/48700] New: [OOP] memory leak with MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700 Summary: [OOP] memory leak with MOVE_ALLOC of polymorphic variables Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 24058 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24058 test-case Running the attached test case through valgrind gives memory leak warnings, both with current trunk and 4.6.0 [sfilippo@donald bug31]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu47 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.7.0 20110418 (experimental) (GCC) [sfilippo@donald bug31]$ gfortran -o testmv3 testmv3.f90 -ggdb [sfilippo@donald bug31]$ valgrind --leak-check=full ./testmv3 ==25909== Memcheck, a memory error detector ==25909== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==25909== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==25909== Command: ./testmv3 ==25909== ==25909== ==25909== HEAP SUMMARY: ==25909== in use at exit: 216 bytes in 4 blocks ==25909== total heap usage: 26 allocs, 22 frees, 12,368 bytes allocated ==25909== ==25909== 40 bytes in 1 blocks are definitely lost in loss record 3 of 4 ==25909==at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==25909==by 0x401425: MAIN__ (testmv3.f90:37) ==25909==by 0x401729: main (testmv3.f90:22) ==25909== ==25909== 176 (96 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4 ==25909==at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==25909==by 0x400DCF: MAIN__ (testmv3.f90:30) ==25909==by 0x401729: main (testmv3.f90:22) ==25909== ==25909== LEAK SUMMARY: ==25909==definitely lost: 136 bytes in 2 blocks ==25909==indirectly lost: 80 bytes in 2 blocks ==25909== possibly lost: 0 bytes in 0 blocks ==25909==still reachable: 0 bytes in 0 blocks ==25909== suppressed: 0 bytes in 0 blocks ==25909== ==25909== For counts of detected and suppressed errors, rerun with: -v ==25909== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
[Bug fortran/48699] [OOP] MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-04-20 13:20:48 UTC --- (In reply to comment #2) See also PR 48700 (memleak with polymorphic vars in MOVE_ALLOC), which might be a duplicate. They are related in the sense that the test cases for this one were obtained while searching for a memleak test case. Whether the root cause is the same is beyond me..
[Bug fortran/47978] New: [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 Summary: [OOP] Invalid INTENT in overriding TBP not detected Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Hello, The attached code looks invalid to me (and to the NAG and XLF compilers), but is accepted by gnu fortran. [sfilippo@localhost bug33]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc Thread model: posix gcc version 4.6.0 20110225 (experimental) (GCC) [sfilippo@localhost bug33]$ gfortran -c try_ext.f90 [sfilippo@localhost bug33]$ [sfilippo@localhost bug33]$ nagfor -c try_ext.f90 -f2003 NAG Fortran Compiler Release 5.3(826),5.2(765) Error: try_ext.f90, line 38: Argument J of overriding type-bound procedure BAR of type EXTFOO has a different INTENT Errors in declarations, no further processing for EXTFOO_MOD [NAG Fortran Compiler error termination, 1 error] --- bash-3.2$ xlf2003 -c try_ext.f90 ** foo_mod === End of Compilation 1 === try_ext.f90, line 25.27: 1514-593 (S) Dummy argument j of overridden binding bar was declared with the INTENT(IN) attribute. The corresponding dummy argument of overriding binding bar must also be declared with the INTENT(IN) attribute. ** extfoo_mod === End of Compilation 2 === 1501-511 Compilation failed for file try_ext.f90.
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-03-03 16:47:24 UTC --- Created attachment 23534 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23534 test-case
[Bug fortran/46448] [4.6 Regression] [OOP] symbol `__copy_...' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448
--- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it
2010-12-31 22:52:03 UTC ---
(In reply to comment #2)
I think you should check whether the symbol is already there using the gsym
(assuming that -fwhole-file is used - but I think that can be assumed ;-).
There should be only one such function per translation unit; it should use
everywhere the same decl (UID) and - of course - it should be not exported
('static') such that you can have the same function in multiple translation
units. (Which is ugly - best would be to have only once per program, but I
think the .mod file is emitted before the CLASS is encountered.)
I just discovered that changing the order of some USE statements in one
intermediate module makes the extra __copy symbol disappear.
While it's a nice workaround, it's a bit suspicious.
[Bug fortran/46838] [OOP] Initialization of polymorphic allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-12-28 13:40:52 UTC --- (In reply to comment #5) (In reply to comment #4) Here's a patch: The patch in comment #4 had a few regressions (e.g. on alloc_comp_basics_1.f90 etc), but the following version regtests cleanly: For me, it cures the reduced test case (bug28.f90) in comment #0, so it's definitely a step in the right direction. Unfortunately in the full application I still get this: [localhost:15473] Signal: Segmentation fault (11) [localhost:15473] Signal code: Address not mapped (1) [localhost:15473] Failing at address: 0x1344133b [localhost:15472] [ 0] /lib64/libpthread.so.0(+0xf4a0) [0x7fae89b8b4a0] [localhost:15472] [ 1] /lib64/libc.so.6(cfree+0x1c) [0x7fae898782dc] [localhost:15472] [ 2] ./ppde(__copy_psb_gen_block_map_mod_psb_gen_block_map_+0x143) [0x4c45b3] [localhost:15472] [ 3] ./ppde(psb_cdcpy_+0x700) [0x4bf850] [localhost:15472] [ 4] ./ppde(psb_dcdbldext_+0x7e2) [0x4b2762] [localhost:15472] [ 5] ./ppde() [0x41985f] [localhost:15472] [ 6] ./ppde() [0x41c6dd] [localhost:15472] [ 7] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fae8981cc5d] [localhost:15472] [ 8] ./ppde() [0x418ef9] [localhost:15472] *** End of error message *** I suppose this means that the original test case did not catch all there was; I guess it would be best to declare this fixed and open a new one, as soon as I have time to get a new reduced test case.
[Bug fortran/47082] New: [OOP] ICE in gfc_conv_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082 Summary: [OOP] ICE in gfc_conv_component_ref Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22858 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22858 test case trunk at r168261: [sfili...@localhost V1]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20101227 (experimental) (GCC) [sfili...@localhost V1]$ gfortran -ggdb -fbacktrace bug29_1.f90 -c bug29_1.f90: In function 'psb_cdall': bug29_1.f90:244:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:501 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/47085] New: [OOP] Problem in allocate( SOURCE=) for polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47085 Summary: [OOP] Problem in allocate( SOURCE=) for polymorphic component Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22859 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22859 test case With trunk at r168261 plus the patch for PR46838 I get the following error when running under valgrind: [sfili...@localhost bug29]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc : (reconfigured) ../gcc-dev/configure --prefix=/usr/local/gnudev --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20101227 (experimental) (GCC) [sfili...@localhost bug29]$ gfortran -o ppde ppde.f90 [sfili...@localhost bug29]$ valgrind ./ppde ==9847== Memcheck, a memory error detector ==9847== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==9847== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==9847== Command: ./ppde ==9847== ==9847== Conditional jump or move depends on uninitialised value(s) ==9847==at 0x400C08: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x4019C7: psb_cdcpy_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401B85: MAIN__ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401BD9: main (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847== ==9847== Conditional jump or move depends on uninitialised value(s) ==9847==at 0x400C2E: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x4019C7: psb_cdcpy_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401B85: MAIN__ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401BD9: main (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847== ==9847== Conditional jump or move depends on uninitialised value(s) ==9847==at 0x400C51: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x4019C7: psb_cdcpy_ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401B85: MAIN__ (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847==by 0x401BD9: main (in /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde) ==9847== ==9847== ==9847== HEAP SUMMARY: ==9847== in use at exit: 648 bytes in 6 blocks ==9847== total heap usage: 22 allocs, 16 frees, 4,473 bytes allocated ==9847== ==9847== LEAK SUMMARY: ==9847==definitely lost: 0 bytes in 0 blocks ==9847==indirectly lost: 0 bytes in 0 blocks ==9847== possibly lost: 0 bytes in 0 blocks ==9847==still reachable: 648 bytes in 6 blocks ==9847== suppressed: 0 bytes in 0 blocks ==9847== Rerun with --leak-check=full to see details of leaked memory ==9847== ==9847== For counts of detected and suppressed errors, rerun with: -v ==9847== Use --track-origins=yes to see where uninitialised values come from ==9847== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6) The test case is reduced from a complex application, where the error shows up as follows: [sfili...@localhost runs]$ ./ppde Generating Matrix (size=64)... The matrix has been generated and assembled in CSR format. -allocation time : 1.42813E-04 -coeff. gen. time : 3.26872E-04 -assemblytime : 6.09159E-04 -total time : 1.11485E-03 Overall matrix creation time : 1.47796E-03 Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + /lib64/libc.so.6(+0x32970) [0x7fa574efe970] + /lib64/libc.so.6(cfree+0x1c) [0x7fa574f462dc] + function __copy_psb_gen_block_map_mod_psb_gen_block_map_ (0x4382E6) at line 97 of file psb_gen_block_map_mod.f03 + function psb_cdcpy_ (0x420B06) at line 93 of file psb_cdcpy.f90 + function ppde (0x403E4A) at line 82 of file ppde.f90 + /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fa574eeac5d] With the reduced test case the segfault is not apparent, but the cause is still operational.
[Bug fortran/46838] [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 --- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-12-15 13:08:12 UTC --- (In reply to comment #2) The default initializer is obtained via expr.c's gfc_default_initializer. The original code gives Overall matrix creation time : 1.69176E-01 [localhost:06639] Signal: Segmentation fault (11) [localhost:06639] Signal code: (128) [localhost:06639] Failing at address: (nil) *** glibc detected *** ./ppde: munmap_chunk(): invalid pointer: 0x0064a8e6 *** === Backtrace: = /lib64/libc.so.6[0x39dc875676] ./ppde(__copy_psb_gen_block_map_mod_psb_gen_block_map_+0x143)[0x4c5f43] ./ppde(psb_cdcpy_+0x5c0)[0x4c11e0] ./ppde(psb_dcdbldext_+0x802)[0x4b3f92] ./ppde[0x419d26] ./ppde[0x41cbdd] /lib64/libc.so.6(__libc_start_main+0xfd)[0x39dc81ec5d] ./ppde[0x419339] i.e. the problem surfaces in a SOURCE= allocation.
[Bug fortran/46838] New: [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838 Summary: [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22672 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22672 test-case Hello, At r167487 the polymorphic component of an INTENT(OUT) dummy starts as ALLOCATED, which is obviously wrong. [sfili...@localhost bug28]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20101206 (experimental) (GCC) [sfili...@localhost bug28]$ gfortran -o bug28 bug28.f90 [sfili...@localhost bug28]$ ./bug28 Generating Matrix (size=512)... Allocated on an intent(OUT) var?
[Bug fortran/46809] New: [OOP] ICE with -fcheck=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809 Summary: [OOP] ICE with -fcheck=all Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it
[Bug fortran/46809] [OOP] ICE with -fcheck=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809 --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-12-05 13:29:12 UTC --- With trunk at r167453 I get [sfili...@localhost bug27]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20101204 (experimental) (GCC) [sfili...@localhost bug27]$ gfortran -fcheck=all -c psb_s_base_mat_impl.f03 psb_s_base_mat_impl.f03: In function 'psb_s_base_transp_2mat': psb_s_base_mat_impl.f03:120:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/46809] [OOP] ICE with -fcheck=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809 --- Comment #2 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-12-05 13:30:41 UTC --- Created attachment 22642 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22642 test case As usual, quite reduced from the original, but not necessarily minimal.
[Bug fortran/46448] [4.6 Regression] [OOP] symbol `__copy_...' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-11-12 10:05:38 UTC --- (In reply to comment #0) /tmp/cciKD2sS.s: Assembler messages: /tmp/cciKD2sS.s:72: Error: symbol `__copy_m0_t_' is already defined The test case works with 4.5. The error is a regression of my recent polymorphic deep copy patch: http://gcc.gnu.org/viewcvs?view=revisionrevision=166368 I think this is the same issue as the one reported by Salvatore here: http://gcc.gnu.org/ml/fortran/2010-11/msg00205.html Yup, it's the same kind of problem.
[Bug fortran/46345] New: ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46345 Summary: ICE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22307 test-case While cutting down a test case for a wrong-code issue, I have produced the following ICE: Driving: gfortran -v .o tp tp.f90 -l gfortran -l m -shared-libgcc gfortran: error: .o: No such file or directory Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel /GCC/mpfr --with-mpc=/home/travel/GCC/mpc Thread model: posix gcc version 4.6.0 20101105 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 tp.f90 -quiet -dumpbase tp.f90 -mtune=generic -march=x86-64 -auxbase tp -version -f intrinsic-modules-path /usr/local/gnu46/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccggWLYz.s GNU Fortran (GCC) version 4.6.0 20101105 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101105 (experimental), GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101105 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101105 (experimental), GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 tp.f90: In function 'ppde': tp.f90:282:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -bash-4.1$
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-11-07 14:58:40 UTC --- (In reply to comment #6) Revision 162456 compiles the tests, but not revision 166102. When compiled, the executable for pr46345 gives Check 0: T a.out(84352) malloc: *** error for object 0x13072: pointer being freed was not allocated ...which is the original problem for which I was trying to open a PR, a wrong allocation status for a scalar component. Salvatore
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-10-26 07:09:41 UTC --- (In reply to comment #0) The following is in a sense a follow up to PR 45451. Assuming that X and Y are both polymorphic (CLASS) and the following operation: ALLOCATE (x, SOURCE=y) or x = y ! Fortran 2008: (Re)alloc on assignment with polymorphic LHS What about MOLD= for polymorphic variables?
[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 sfilippone at uniroma2 dot it 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/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #3 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-09-26 07:33:13 UTC --- (In reply to comment #2) It is very likely a duplicate of pr45783. The code compiles at r164549
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #4 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-09-26 07:43:51 UTC --- (In reply to comment #3) (In reply to comment #2) It is very likely a duplicate of pr45783. The code compiles at r164549 and fails at r164550
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 --- Comment #6 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-09-26 10:27:41 UTC --- (In reply to comment #5) Confirmed. I do not yet see how this is related to my commit, but will look into it of course. Thanks for the report! Well, considering how many times I have been burned by things that should not have anything to do with, it was relatively easy to home in onto the only change in recent days that had touched SELECT TYPE :-) As I read somewhere Interesting problems prove their worth by biting back Salvatore
[Bug fortran/45795] New: [OOP] ICE in in gfc_add_component_ref plus bogus error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 Summary: [OOP] ICE in in gfc_add_component_ref plus bogus error message Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 21886 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21886 test case Hello, This was working until a few days ago, now it's broken: the compiler gives a bogus error message, and then ICEs. Trunk at r164617: [sfili...@localhost bug24]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20100925 (experimental) (GCC) [sfili...@localhost bug24]$ gfortran -c bug24.f03 bug24.f03:68.10: call b%cp_to_foo(tmp,info) 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(base) to CLASS(s_base) bug24.f03:11:0: internal compiler error: in gfc_add_component_ref, at fortran/class.c:77 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #10 from sfilippone at uniroma2 dot it 2010-09-08 15:35 --- (In reply to comment #9) I have found a cure. The original configuration had GMP, MPFR and MPC built and installed under the user home directory (there were neither mpfr nor mpc system-wide, and gmp was a bit old); somehow this is the root cause of the problem, despite --with-gmp and friends. Building the three packages from source in the GCC source tree gets the bootstrap process beyond the previous stopping point (currently in middle of stage 3). Maybe this should be added to the platform-specific notes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #12 from sfilippone at uniroma2 dot it 2010-09-08 16:11 --- (In reply to comment #11) (In reply to comment #10) How did you configure those prebuilt gmp/mpfr/mpc libraries installed under your home directory? In particular, did you configure them all with --disable-shared? If not, then you have to be extremely careful to avoid unintended mismatches, and in some cases incorrectly duplicated state. I know for a fact that prebuilt gmp/mpfr/mpc installed in a private location works fine on powerpc64-linux when all are configured with --disable-shared. Indeed, they were shared. The thing that caught me is that I have built GCC hundreds of times on i686/x86_64 with shared, private dir gmp/mpfr/mpc without a problem, so I went ahead and did the same on this machine; I normally bootstrap on my two main machines the 4.6 trunk every other day. Of course I am not claiming I didn't do anything wrong, just that it was not obvious from the various docs, including platform notes, that it was safer to use disable-shared or build from the GCC source tree. Anyway, my problem is fixed, and I know a bit more than yesterday; thanks everybody. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #9 from sfilippone at uniroma2 dot it 2010-09-07 07:20 ---
(In reply to comment #8)
Created an attachment (id=21673)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21673action=view) [edit]
Modifying the conftest source gives the following:
[snfi...@josquin libiberty]$ sh cmd.sh
[snfi...@josquin libiberty]$ ./conftest
Failing index 97 a
Reason: islower 2 ISLOWER 0 toupper A TOUPPER a
So the ISLOWER macro is (apparently) giving the wrong result.
---
#include ctype.h
#include stdlib.h
#include stdio.h
#if ((' ' 0x0FF) == 0x020)
# define ISLOWER(c) ('a' = (c) (c) = 'z')
# define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
#else
# define ISLOWER(c)(('a' = (c) (c) = 'i') ||
('j' = (c) (c) = 'r') || ('s' = (c) (c) = 'z'))
# define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
#endif
#define XOR(e, f) (((e) !(f)) || (!(e) (f)))
int
main ()
{
int i;
for (i = 0; i 256; i++)
if (XOR (islower (i), ISLOWER (i))
|| toupper (i) != TOUPPER (i)) {
fprintf(stderr,Failing index %d %c \n,i,i);
fprintf(stderr,Reason: islower %d ISLOWER %d toupper %c TOUPPER %c
\n,
islower(i), ISLOWER (i),
toupper (i) , TOUPPER (i));
return 2;
}
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug fortran/45494] New: [OOP] Wrong dummy argument not rejected
Hello, The attached code is rejected by XLF 13.1 and NAG, but is accepted by gfortran. The problem is that the second instance of the call to the MOLD method passes an object that is not type compatible. ==gfortran= [sfili...@localhost bug24]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100902 (experimental) (GCC) [sfili...@localhost bug24]$ gfortran -c bug24.f03 [sfili...@localhost bug24]$ xlf === bash-3.2$ which xlf /opt/IBM/compilers/xlf13.1/usr/bin/xlf bash-3.2$ xlf2003 -c bug24.f03 ** foo_mod === End of Compilation 1 === ** foo_2_mod === End of Compilation 2 === ** foo_3_mod === End of Compilation 3 === bug24.f03, line 43.17: 1513-061 (S) Actual argument attributes do not match those specified by an accessible explicit interface. ** bar === End of Compilation 4 === 1501-511 Compilation failed for file bug24.f03. -- Summary: [OOP] Wrong dummy argument not rejected Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45494
[Bug fortran/45494] [OOP] Wrong dummy argument not rejected
--- Comment #1 from sfilippone at uniroma2 dot it 2010-09-02 10:16 --- Created an attachment (id=21653) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21653action=view) test-case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45494
[Bug bootstrap/45482] New: Bootstrap fails on PPC error: conflicting types for 'malloc'
-in function 'free' [enabled by default] make[3]: *** [regex.o] Error 1 make[3]: Leaving directory `/home/snfilip/GNUBUILD/obj-4.6.0/libiberty' make[2]: *** [all-stage2-libiberty] Error 2 make[2]: Leaving directory `/home/snfilip/GNUBUILD/obj-4.6.0' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/snfilip/GNUBUILD/obj-4.6.0' make: *** [bootstrap] Error 2 -- Summary: Bootstrap fails on PPC error: conflicting types for 'malloc' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #1 from sfilippone at uniroma2 dot it 2010-09-01 13:44 --- Created an attachment (id=21642) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21642action=view) Main config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #2 from sfilippone at uniroma2 dot it 2010-09-01 13:44 --- Created an attachment (id=21643) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21643action=view) stage 1 libiberty/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #3 from sfilippone at uniroma2 dot it 2010-09-01 13:44 --- Created an attachment (id=21644) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21644action=view) stage 1 libiberty/config.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #4 from sfilippone at uniroma2 dot it 2010-09-01 13:45 --- Created an attachment (id=21645) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21645action=view) stage 2 libiberty/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #5 from sfilippone at uniroma2 dot it 2010-09-01 13:45 --- Created an attachment (id=21646) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21646action=view) stage 2 libiberty/config.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[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 #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 #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 #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=21613action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] New: [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
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. === [sfili...@donald bug23]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100830 (experimental) (GCC) [sfili...@donald bug23]$ gfortran -ggdb -o bug23 bug23.f03 [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) -- Summary: [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown
[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=21592action=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 #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 #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/45438] New: [OOP] ICE with -fcheck=pointer
Hello, Trying to debug another issue, I have found this ICE, trunk at r163595 [sfili...@localhost bug22]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100827 (experimental) (GCC) [sfili...@localhost bug22]$ gfortran -ggdb -c bug22.f03 [sfili...@localhost bug22]$ gfortran -ggdb -fcheck=pointer -c bug22.f03 bug22.f03: In function 'base_get_nz_row': bug22.f03:58:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [OOP] ICE with -fcheck=pointer Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45438] [OOP] ICE with -fcheck=pointer
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 09:04 --- Created an attachment (id=21581) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21581action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45439] New: [OOP] SELECT TYPE bogus complaint about INTENT
With trunk at r163595, I get an error message which is totally bogus: = [sfili...@localhost bug21]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100827 (experimental) (GCC) [sfili...@localhost bug21]$ gfortran -c bug21.f03 bug21.f03:91.11: call aa%mv_to_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT bug21.f03:92.33: if (info == success_) call aa%mv_from_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT == -- Summary: [OOP] SELECT TYPE bogus complaint about INTENT Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 11:15 --- Created an attachment (id=21583) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21583action=view) test case The code compiles cleanly with XLF. If I switch the commented lines in the CLASS DEFAULT clause, it compiles cleanly (but I am not sure about the runtime behaviour, as I have seen other problems down the road in the original application). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #3 from sfilippone at uniroma2 dot it 2010-08-27 07:37 --- (In reply to comment #2) It turns out this bug is rather easy to fix. The problem was the we used the temporary needed for the TYPE IS clause also in the CLASS DEFAULT clause (where we need none). The following patch fixes it (haven't checked for regressions yet): Hi, First, the patch did not apply cleanly, the first hunk was rejected. I applied it by hand, and I got a problem down the road in my library: === gfortran -ggdb -I.. -I../modules -I. -c psb_srwextd.f90 psb_srwextd.f90:76.13: call aa%mv_to_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT psb_srwextd.f90:84.39: if (info == psb_success_) call aa%mv_from_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT The relevant piece of code is as follows: subroutine psb_srwextd(nr,a,info,b,rowscale) use psb_sparse_mod, psb_protect_name = psb_srwextd implicit none ! Extend matrix A up to NR rows with empty ones (i.e.: all zeroes) integer, intent(in) :: nr type(psb_s_sparse_mat), intent(inout):: a integer,intent(out) :: info type(psb_s_sparse_mat), intent(in), optional :: b logical,intent(in), optional :: rowscale integer :: i,j,ja,jb,err_act,nza,nzb character(len=20) :: name, ch_err type(psb_s_coo_sparse_mat):: actmp logical rowscale_ name='psb_srwextd' info = psb_success_ call psb_erractionsave(err_act) if (nr a%get_nrows()) then select type(aa= a%a) type is (psb_s_csr_sparse_mat) if (present(b)) then call psb_rwextd(nr,aa,info,b%a,rowscale) else call psb_rwextd(nr,aa,info,rowscale=rowscale) end if type is (psb_s_coo_sparse_mat) if (present(b)) then call psb_rwextd(nr,aa,info,b%a,rowscale=rowscale) else call psb_rwextd(nr,aa,info,rowscale=rowscale) end if class default call aa%mv_to_coo(actmp,info) if (info == psb_success_) then if (present(b)) then call psb_rwextd(nr,actmp,info,b%a,rowscale=rowscale) else call psb_rwextd(nr,actmp,info,rowscale=rowscale) end if end if if (info == psb_success_) call aa%mv_from_coo(actmp,info) end select end if if (info /= psb_success_) goto call psb_erractionrestore(err_act) return continue call psb_erractionrestore(err_act) if (err_act == psb_act_abort_) then call psb_error() return end if return end subroutine psb_srwextd == The calls to AA%MV_TO ad AA%MV_FROM should be able to modify AA, since 1. AA = A%A 2. A is an INOUT dummy argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-27 11:38 --- (In reply to comment #4) (In reply to comment #3) I tried to reproduce this by modifying your original test case, but did not succeed so far. Can you provide a standalone test case for this problem? My feeling is that this is another bug uncovered by the fix for the previous one. The patch in comment #2 is free of testsuite regressions and certainly does the right thing. Ok, go ahead with this fix, and I will open a new PR as appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45420] [OOP] polymorphic TBP call in a CLASS DEFAULT clause
--- Comment #6 from sfilippone at uniroma2 dot it 2010-08-27 14:40 --- (In reply to comment #3) end if class default call aa%mv_to_coo(actmp,info) if (info == psb_success_) then if (present(b)) then call psb_rwextd(nr,actmp,info,b%a,rowscale=rowscale) else call psb_rwextd(nr,actmp,info,rowscale=rowscale) end if end if if (info == psb_success_) call aa%mv_from_coo(actmp,info) end select If however I change the code as follows: select type(aa = a%a) class default call a%a%mv_to_coo(actmp,info) ... it compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
[Bug fortran/45384] [OOP] double free with SELECT TYPE
--- Comment #4 from sfilippone at uniroma2 dot it 2010-08-24 10:24 ---
(In reply to comment #3)
With dump-tree-original I see this code snippet:
finally
{
if (aa.$data != 0B)
{
__builtin_free ((void *) aa.$data);
}
}
I believe this is wrong, because aa.$data is always an alias to an
independently allocated data area, hence the double free. Of course I have no
idea why this happens or how to fix it, but you already guessed that :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
[Bug fortran/45384] [OOP] double free with SELECT TYPE
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-24 12:50 --- (In reply to comment #3) Reduced test case: program bug20 type :: d_base_sparse_mat integer :: v(10) = 0. end type d_base_sparse_mat class(d_base_sparse_mat),allocatable :: a allocate (d_base_sparse_mat :: a) select type(aa = a) type is (d_base_sparse_mat) write(0,*) 'NV = ',size(aa%v) class default write(0,*) 'Not implemented yet ' end select end program bug20 Note: The double free only happens when an associate-name is used. Changing the original example as follows: subroutine doit(a) type(d_sparse_mat), intent(in) :: a integer :: i , nv call doselect(a%a) end subroutine doit subroutine doselect(aa) class(base_sparse_mat) :: aa select type(aa) type is (d_base_sparse_mat) nv = size(aa%v) write(0,*) 'NV = ',nv class default write(0,*) 'Not implemented yet ' end select end subroutine doselect makes it work. However, when the same change is applied to the original library, a double free pops up in another place, unrelated to this issue; this would indicate that there are other instances of some sort of flaw in the cleanup of temporaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
[Bug fortran/45384] [OOP] double free with SELECT TYPE
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-24 13:05 --- (In reply to comment #6) Cf. PR 44047 (which is similar to this, except that the polymorphic selector itself is allocatable). Yes, there indeed is a family air to this problem.it's probably one and the same issue: correct cleanup of the temporary. From its description, I would expect a solution to fix bot PRs. Eagerly waiting for one such fix (to test against the full application) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
[Bug fortran/45384] New: [OOP] double free with SELECT TYPE
The attached and rather innocuous looking code generates the subject error. It is a simplified version of a much more complex test case (in which the select type is entered within a loop and the error shows up at the second iteration) === [sfili...@localhost bug20]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100823 (experimental) (GCC) [sfili...@localhost bug20]$ gfortran -o bug20 bug20.f90 [sfili...@localhost bug20]$ ./bug20 NV = 10 *** glibc detected *** ./bug20: double free or corruption (fasttop): 0x018d8ae0 *** === Backtrace: = /lib64/libc.so.6[0x3381475676] ./bug20[0x400b53] ./bug20[0x400b91] /lib64/libc.so.6(__libc_start_main+0xfd)[0x338141ec5d] ./bug20[0x4007a9] === Memory map: 0040-00401000 r-xp 08:09 983344 /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug20/bug20 00601000-00602000 rw-p 1000 08:09 983344 /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug20/bug20 018d8000-018f9000 rw-p 00:00 0 [heap] 338100-338101e000 r-xp 08:06 4964354 /lib64/ld-2.12.so 338121e000-338121f000 r--p 0001e000 08:06 4964354 /lib64/ld-2.12.so 338121f000-338122 rw-p 0001f000 08:06 4964354 /lib64/ld-2.12.so 338122-3381221000 rw-p 00:00 0 338140-3381575000 r-xp 08:06 4964358 /lib64/libc-2.12.so 3381575000-3381775000 ---p 00175000 08:06 4964358 /lib64/libc-2.12.so 3381775000-3381779000 r--p 00175000 08:06 4964358 /lib64/libc-2.12.so 3381779000-338177a000 rw-p 00179000 08:06 4964358 /lib64/libc-2.12.so 338177a000-338177f000 rw-p 00:00 0 338180-3381883000 r-xp 08:06 4964404 /lib64/libm-2.12.so 3381883000-3381a82000 ---p 00083000 08:06 4964404 /lib64/libm-2.12.so 3381a82000-3381a83000 r--p 00082000 08:06 4964404 /lib64/libm-2.12.so 3381a83000-3381a84000 rw-p 00083000 08:06 4964404 /lib64/libm-2.12.so 3382c0-3382cf1000 r-xp 08:06 5092887 /usr/lib64/libgfortran.so.3.0.0 3382cf1000-3382ef1000 ---p 000f1000 08:06 5092887 /usr/lib64/libgfortran.so.3.0.0 3382ef1000-3382ef3000 rw-p 000f1000 08:06 5092887 /usr/lib64/libgfortran.so.3.0.0 3382ef3000-3382ef4000 rw-p 00:00 0 338500-3385016000 r-xp 08:06 4964412 /lib64/libgcc_s-4.4.4-20100630.so.1 3385016000-3385215000 ---p 00016000 08:06 4964412 /lib64/libgcc_s-4.4.4-20100630.so.1 3385215000-3385216000 rw-p 00015000 08:06 4964412 /lib64/libgcc_s-4.4.4-20100630.so.1 7f7a0b89c000-7f7a0b8a rw-p 00:00 0 7f7a0b8d-7f7a0b8d1000 rw-p 00:00 0 7fffc443b000-7fffc445 rw-p 00:00 0 [stack] 7fffc4563000-7fffc4564000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Abortito (core dumped) -- Summary: [OOP] double free with SELECT TYPE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
[Bug fortran/45384] [OOP] double free with SELECT TYPE
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-23 14:44 --- Created an attachment (id=21548) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21548action=view) test-case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45384
