[Bug fortran/89069] ICE in select type with function returning class array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069 --- Comment #3 from Antony Lewis --- This bug is still valid as of gcc 11.2.1 20220114 15 | end module test | 1 internal compiler error: Segmentation fault 0x160a5b7 internal_error(char const*, ...) ???:0 0x764849 gfc_class_data_get(tree_node*) ???:0 0x7b0111 gfc_trans_block_construct(gfc_code*) ???:0 0x762224 gfc_generate_function_code(gfc_namespace*) ???:0 0x73c1d1 gfc_generate_module_code(gfc_namespace*) ???:0 0x6dd185 gfc_parse_file() ???:0
[Bug fortran/103942] [10 Regression] invalid memory reference with allocatable string and class(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103942 --- Comment #1 from Antony Lewis --- Also broken in 9.4.1 20220107.
[Bug fortran/103942] New: [10 Regression] invalid memory reference with allocatable string and class(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103942 Bug ID: 103942 Summary: [10 Regression] invalid memory reference with allocatable string and class(*) Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- The code works as expected in 9.3.1 20200614. In 10.3.1 20220107 and trunk it gives Program received signal SIGSEGV: Segmentation fault - invalid memory reference. program tester character(LEN=:), allocatable :: S S = 'CMB' call TT(trim(S)) contains subroutine TT(S) class(*), intent(in) :: S class(*), allocatable :: S2 allocate(S2, source=S) end subroutine TT end program tester
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #10 from Antony Lewis --- I think you are right, it does not seem to fix it. I made https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 (may also be duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391)
[Bug fortran/103898] New: [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 Bug ID: 103898 Summary: [12 Regression] ICE: gimplification failed Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- For full log see https://app.travis-ci.com/github/cmbant/CosmoMC/jobs/552809686. The relevant stack trace is [ 94/125] Processing src/bflike/long_intrinsic_smw.f90 gimplification failed: MAX_EXPR <_21, 0> unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f1b60196738 precision:64 min max pointer_to_this > arg:0 def_stmt _21 = _20 + 1; version:21> arg:1 constant 0> /cosmomc/code/plc_3.0/plc-3.01/src/bflike/long_intrinsic_smw.f90:155:36 start: /cosmomc/code/plc_3.0/plc-3.01/src/bflike/long_intrinsic_smw.f90:155:36 finish: /cosmomc/code/plc_3.0/plc-3.01/src/bflike/long_intrinsic_smw.f90:155:36> /cosmomc/code/plc_3.0/plc-3.01/src/bflike/long_intrinsic_smw.f90:155:36: 155 |mysize = size(array, dim=dim) |^ internal compiler error: gimplification failed 0x1daeb37 internal_error(char const*, ...) ???:0 0xc4a9b6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4713f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4aa16 gimplify_stmt(tree_node**, gimple**) ???:0 0xc474e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4aa16 gimplify_stmt(tree_node**, gimple**) ???:0 0xc4848b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4aa16 gimplify_stmt(tree_node**, gimple**) ???:0 0xc479e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4aa16 gimplify_stmt(tree_node**, gimple**) ???:0 0xc474e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4aa16 gimplify_stmt(tree_node**, gimple**) ???:0 0xc4848b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc4aa16 gimplify_stmt(tree_node**, gimple**) ???:0 0xc479e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ???:0 0xc58d19 gimplify_body(tree_node*, bool) ???:0 0xc5915d gimplify_function_tree(tree_node*) ???:0 0xa94487 cgraph_node::analyze() ???:0 0xa97c6d symbol_table::finalize_compilation_unit() ???:0 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The relevant source code is in https://pla.esac.esa.int/pla/aio/product-action?COSMOLOGY.FILE_ID=COM_Likelihood_Code-v3.0_R3.01.tar.gz This broke in trunk relatively recently, though at least a month ago. I don't have a reduced test case (this is not my code).
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #7 from Antony Lewis --- I see similar error in another fortran code, full trace in https://app.travis-ci.com/github/cmbant/CosmoMC/jobs/552809686
[Bug sanitizer/100987] New: make distclean error "hwasan: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100987 Bug ID: 100987 Summary: make distclean error "hwasan: No such file or directory" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Last known working trunk build was 22 Nov 2020. Since then a "make distclean" fails with this error after building C,C++, fortran (failed from weekly auto-build after that). See full dockerfile to reproduce at https://github.com/cmbant/docker-gcc-build/blob/d5eefe8bdbe0b683a7bd4ca09caf4c9bba8fc429/Dockerfile
[Bug fortran/89067] Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 --- Comment #4 from Antony Lewis --- I agree it may be technically correct, but it is not helpful (esp. if your base class is an empty hierarchy root class, so all derived classes in the program would give this same error).
[Bug fortran/94109] [8/9/10/11 Regression] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #20 from Antony Lewis --- Tried trunk and gcc8, and both look good - many thanks for the fixes! Is there no way to update 7.x? Since the buggy 7/8/9 version has also propagated quite widely, if you know any likely workaround that might be useful to note (the "final" bug was obvious how to work around, but not the last one).
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #12 from Antony Lewis --- Valgrid report is HEAP SUMMARY: ==23446== in use at exit: 40,000 bytes in 1 blocks ==23446== total heap usage: 26 allocs, 25 frees, 93,657 bytes allocated ==23446== ==23446== 40,000 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==23446==at 0x483577F: malloc (vg_replace_malloc.c:299) ==23446==by 0x402052: __debug_MOD_leaker (bug.f90:21) ==23446==by 0x4021DA: MAIN__ (bug.f90:32) ==23446==by 0x402211: main (bug.f90:30) ==23446== ==23446== LEAK SUMMARY: ==23446==definitely lost: 40,000 bytes in 1 blocks ==23446==indirectly lost: 0 bytes in 0 blocks ==23446== possibly lost: 0 bytes in 0 blocks ==23446==still reachable: 0 bytes in 0 blocks ==23446== suppressed: 0 bytes in 0 blocks
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #11 from Antony Lewis --- It took ages to narrow this down, but here's a simple test case that still gives a leak with valgrind in gcc-8 HEAD, 8.4.0, 9.3.0 (OK with 7.4.0) module debug implicit none Type Tester real, dimension(:), allocatable :: Dat, Dat2 end Type Type TestType2 Type(Tester) :: T end type TestType2 contains subroutine Leaker class(TestType2), pointer :: ActiveState Type(Tester) :: Temp allocate(Temp%Dat2(1)) allocate(TestType2::ActiveState) ActiveState%T = Temp deallocate(ActiveState) end subroutine end module program run use debug call Leaker() end program
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #7 from Antony Lewis --- However the reduced case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 now seems to be OK. However on trunk, the fix for 94361 seems to have introduced a leak that was not there before: https://travis-ci.org/github/cmbant/CAMB/jobs/692470383 (was fine from gcc source build from 5 days ago - I just reran it with the new docker image)
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #6 from Antony Lewis --- Thanks for looking in to it. I tried rebuilding my gcc8 docker and rerunning. It now reports GNU Fortran (GCC) 8.4.1 20200602, however the leak still seems to be there? https://travis-ci.org/github/cmbant/CAMB/jobs/660297689
[Bug fortran/94361] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 --- Comment #3 from Antony Lewis --- On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also does not (but 9.2.0 does)... so not exactly sure what this means about when it was introduced.
[Bug fortran/94361] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 --- Comment #2 from Antony Lewis --- I tried it on another system where gfortran 6.5 and 7.4.0 that don't leak, but 8.4.0 does, so in that sense at least I think it is a regression.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #4 from Antony Lewis --- Not sure why no one has at least picked up on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 since it is a reproducible regression with a simple test case, an a bug that effectively kills some previously-working code from 7.x updates onwards?
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #3 from Antony Lewis --- Although my reduced test in the other id case is one problem, it appears that is not the only memory leak. Someone tested else on various gcc versions and still found: versionmemory leak 7.3.0 no 8.2.0 no 7.5.0 yes 8.4.0 yes 9.2.0 yes 9.3.0 yes So it certainly looks like a regression.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #2 from Antony Lewis --- This may be the test case, though I'm not 100% sure: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
[Bug fortran/94361] New: Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 Bug ID: 94361 Summary: Memory leak in nested types with final Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- The code below leaks memory (mem grows with each loop interation), but does not if the "FINAL" is commented. The issue is also present in trunk (10.0.1 20200218), and may be a reduced test case for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 (in which case the problem was introduced around 8.3.1, but I have not tested versions extensively). module debug private Type TypeWithFinal contains FINAL :: finalizer !No leak if this line is commented end type Type Tester real, dimension(:), allocatable :: Dat Type(TypeWithFinal) :: X end Type Type :: TestType2 Type(Tester) :: T end type TestType2 public Leaker contains subroutine Leaker type(TestType2) :: Test allocate(Test%T%Dat(1)) end subroutine subroutine finalizer(this) Type(TypeWithFinal) :: this end subroutine finalizer end module program run use debug implicit none integer i do i=1, 1 call Leaker() call sleep(1) end do end program
[Bug fortran/94109] New: Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 Bug ID: 94109 Summary: Memory leak introduced in 8.3.0->8.3.1 Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- I see an apparent memory leak introduced in running code between ubuntu-toolchain-r/test gfortran 8.3.0 OK Source 20200106 build gfortran 8.3.1 bad (also current 8 and 10 git heads). I have not tracked down where it is coming from, but there is a complete example on git with travis reports: 8.3.1 issue https://travis-ci.org/cmbant/CAMB/jobs/660297689 GCC 9 9.2.1 20191102 issue (with otherwise same config as 8.3.0 below) https://travis-ci.org/cmbant/CAMB/jobs/660297688 8.3.0 OK https://travis-ci.org/cmbant/CAMB/jobs/660297687 (see memory counts at bottom of trace as function of loop count, produced from python). To produce output locally do git clone --branch test https://github.com/cmbant/CAMB.git and run setup.py and then setup.py test (with py3.6+). I'm hoping this narrowish version window will enable someone to guess at the cause of the issue. I looked at this because someone reported a large memory leak on gfortran 9.2 OS X that cannot be reproduced with ifort, or gfortran versions 6-8.3.0 (on linux the leak seems much smaller). The code uses multiple nested allocatable F2003 class types.
[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 --- Comment #4 from Antony Lewis --- Not sure why that rather than other dependency options, been like that for ages (guessing: maybe because of mpif.h?).
[Bug fortran/90927] New: [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 Bug ID: 90927 Summary: [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- ICE with version GNU Fortran (GCC) 10.0.0 20190618 compiling https://github.com/cmbant/forutils.git For full output see https://travis-ci.org/cmbant/forutils/jobs/523880280
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #11 from Antony Lewis --- I posted remaining ICE in 9.0.0 20190119 as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
[Bug fortran/89069] New: ICE in select type with function returning class array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069 Bug ID: 89069 Summary: ICE in select type with function returning class array pointer Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Follow up to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566, seg fault ICE with gfortran 6.5-9.0 module test contains function getP() class(*), pointer :: getP(:) end function getP subroutine SegFaulter() class(*), pointer :: Pt => null() select type (P=>getP()) type is (real) end select end subroutine end module test
[Bug fortran/89067] Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 --- Comment #1 from Antony Lewis --- The error message on this code subroutine test type x end type type, extends(x):: y integer ii end type type(y) yy yy%i=1 end subroutine is Error: 'i' at (1) is not a member of the 'x' structure But it should refer to the 'y' structure, not the base class 'x'. Obviously minor and low priority, but more less helpful if y is a deep derived class.
[Bug fortran/89067] New: Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 Bug ID: 89067 Summary: Inaccurate error message: 'i' at (1) is not a member of the 'x' structure Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: ---
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #10 from Antony Lewis --- In the latest 9.0 trunk I still see what looks like a similar ICE error (though I have not tried to isolate it again). See https://travis-ci.org/cmbant/forutils/builds/483365115 when running test script in https://github.com/cmbant/forutils/tree/gcc_bug1 . (code is reported invalid in gcc6, but SEG faults in 7,8,9).
[Bug fortran/88980] New: [9 regression] segfault on allocatable string member assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980 Bug ID: 88980 Summary: [9 regression] segfault on allocatable string member assignment Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- This code gives seg fault in 9.0.0 20181010 and 9.0.0 20190103, OK in 8.2.1: (same with P pointer or allocatable) program tester call gbug contains subroutine gbug type TNameValue character(LEN=:), allocatable :: Name end type TNameValue type TNameValue_pointer Type(TNameValue), allocatable :: P end type TNameValue_pointer Type TType type(TNameValue_pointer), dimension(:), allocatable :: Items end type TType Type(TType) T allocate(T%Items(2)) allocate(T%Items(2)%P) T%Items(2)%P%Name = 'test' end subroutine gbug end program tester
[Bug fortran/88685] [8/9 regression] pointer class array argument indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685 --- Comment #2 from Antony Lewis --- I think the individual elements are correct, it's the array indexing operations that are wrong (this is clearer in the longer example; looks a like wrong stride). E.g. printing this in the main program after calling doit print *, arr(1,1)%CL also gives 1, -1, -1.
[Bug fortran/88685] New: 8/9 regression] pointer class array argument indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685 Bug ID: 88685 Summary: 8/9 regression] pointer class array argument indexing Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Created attachment 45333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45333=edit Test case This code works in 7.3.1, but gives wrong answers in 8.3.1 and trunk (outputs should all be the same, but are not): program tester implicit none Type TArr integer, allocatable :: CL(:) end Type TArr type(TArr), allocatable, target :: arr(:,:) class(TArr), pointer:: Cls(:,:) integer i allocate(arr(1,1)) allocate(arr(1,1)%CL(3)) arr(1,1)%CL=-1 cls => arr call doit(cls) contains subroutine doit(cls) class(TArr), pointer :: Cls(:,:) cls(1,1)%CL(:) = 1 print *, 'CL = ', Cls(1,1)%CL print *, 'CL(i)= ', Cls(1,1)%CL(1),Cls(1,1)%CL(2),Cls(1,1)%CL(3) end subroutine doit end program tester A longer variation is attached that's closer to real case where I found it. It can give rise to very hard-to-trace bugs, in my full real-world code it showed up as a mysterious seg fault in random places. Looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336, but is not fixed in nightly build.
[Bug fortran/87580] New: Wrong bounds for sourced allocated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87580 Bug ID: 87580 Summary: Wrong bounds for sourced allocated array Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Bounds of vec2 are wrong in this example (0, 9) instead of (1, 10) as expected (which can lead to all sorts of wrong results). Also in 6.4. program tester real(kind(1.d0)), allocatable :: vec2(:) real(kind(1.d0)) vec(10) allocate(vec2, source=vec*2.) print *, lbound(vec), ubound(vec) print *, lbound(vec2), ubound(vec2) end program tester
[Bug fortran/87566] New: ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 Bug ID: 87566 Summary: ICE with class(*) and select Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Created attachment 44818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44818=edit Full test case Segmentation fault ICE compiling with 6.4. 7.3 or 8.2.0. subroutine AddArray() type Object_array_pointer class(*), pointer :: p(:) => null() end type Object_array_pointer class(*), pointer :: Pt => null() select type (Pt) class is (object_array_pointer) select type (Point=> Pt%P) end select end select end subroutine AddArray
[Bug fortran/85641] New: [7/8 Regression] ICE with string concatenate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85641 Bug ID: 85641 Summary: [7/8 Regression] ICE with string concatenate Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- This worked for a long time in gcc 7, I think it broke in gcc 7.3 (not exactly sure which minor version). It is also broken in gcc 8 and latest master: gfortran -c test.f90 where test.f90 is program tester character(LEN=:), allocatable :: fields integer j character(LEN=4), parameter :: CMB_CL_Fields = 'TEBP' fields = '' j=1 fields = fields // CMB_CL_Fields(j:j) end program tester
[Bug fortran/70748] [6/7 Regression] ICE with debug in gfc_trans_block_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748 Antony Lewis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Antony Lewis --- Resolved by other changes
[Bug fortran/70748] [6/7 Regression] ICE with debug in gfc_trans_block_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748 --- Comment #2 from Antony Lewis --- I just tried this with 7.0.0 20160603, and seems it may have been fixed?
[Bug fortran/70748] New: GCC6 Regression: ICE with debug in gfc_trans_block_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748 Bug ID: 70748 Summary: GCC6 Regression: ICE with debug in gfc_trans_block_construct Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Run "make Debug" on code at https://github.com/cmbant/forutils/ gfortran -cpp -ffree-line-length-none -fmax-errors=4 -MMD -g -O0 -o IniObjects.o -c ../IniObjects.f90 ../IniObjects.f90:348:0: S = S(i+2:) internal compiler error: in gfc_trans_block_construct, at fortran/trans-stmt.c:1788 0x6e30e1 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:1788 0x67f637 trans_code ../../gcc/fortran/trans.c:1785 0x6dac43 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1299 0x6dac54 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1303 0x6e188a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1330 0x67f6a7 trans_code ../../gcc/fortran/trans.c:1777 0x6dac43 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1299 0x6e188a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1330 0x67f6a7 trans_code ../../gcc/fortran/trans.c:1777 0x6e3e2d gfc_trans_do_while(gfc_code*) ../../gcc/fortran/trans-stmt.c:2294 0x67f657 trans_code ../../gcc/fortran/trans.c:1797 0x6dac43 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1299 0x6e188a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1330 0x67f6a7 trans_code ../../gcc/fortran/trans.c:1777 0x6a302c gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6154 0x682b21 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2058 0x63b54d translate_all_program_units ../../gcc/fortran/parse.c:5600 0x63b54d gfc_parse_file() ../../gcc/fortran/parse.c:5819 0x67c985 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:201 Please submit a full bug report, with preprocessed source if appropriate. Appeared sometime in gcc in the last couple of months, also in v7 master.
[Bug fortran/69422] Unexpected result with allocatable character type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69422 --- Comment #4 from Antony Lewis --- But "source" is allocatable, not a pointer? (the pointer P is explicitly allocated in the example)
[Bug fortran/69422] New: Unexpected result with allocatable character type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69422 Bug ID: 69422 Summary: Unexpected result with allocatable character type component Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- With the current svn master branch the following code prints out nothing for 'test result': module funcs implicit none Type T character(LEN=:), allocatable :: source end type T type TPointer Type(T), pointer :: P end type TPointer end module program Test1 use funcs Type(TPointer) :: X allocate(X%P) X%P%Source = 'test string' print *, 'test result = ', X%P%Source end program Test1 This may be a regression from earlier 6.0 commits, but not sure.
[Bug fortran/69423] New: Invalid optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423 Bug ID: 69423 Summary: Invalid optimization Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Using latest svn master branch, the follow code produces wrong results when compiled with -O1 and higher optimizations: program tester character(LEN=:), allocatable :: S S= test(2) contains function test(alen) character(LEN=:), allocatable :: test integer alen, i do i = alen, 1, -1 test = 'test' exit end do !This line prints nothing when compiled with -O1 and higher print *, test end function test end program tester
[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275 --- Comment #6 from Antony Lewis antony at cosmologist dot info --- Not sure about that - 7.1.12 of 2008 is about constants, but in the example the type instance is not a constant? The example is fine in ifort (and used in cosmomc?). Antony -Original Message- From: vehre at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: 20 March 2015 11:59 AM To: ant...@cosmologist.info Subject: [Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275 --- Comment #5 from vehre at gcc dot gnu.org --- Completely right, the initial test is still not compilable. But this is because assigning to an allocatable component in an initializer is not allowed by the standards: F2003, 7.1.7 (3) and also in F2008, 7.1.12 (3). So the correct code would be: module A Type T character(LEN=:), allocatable :: S end type Type(T) :: TestObj = T(NULL()) TestObj%S = 'string' contains end module which compiles and runs w/o error. Standard compliant implementation is tested for in gfortran.dg/alloc_comp_init_expr.f03 only far allocatable arrays, but that's near enough for char arrays for me. -- You are receiving this mail because: You reported the bug.
[Bug fortran/64787] New: Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787
Bug ID: 64787
Summary: Invalid code on sourced allocation of class(*)
character string
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
On trunk
module X
contains
subroutine AddCopy(C)
class(*), intent(in) :: C
class(*), pointer :: P
allocate(P, source=C)
end subroutine
end module X
program test
use X
call AddCopy('test string')
end program test
compiles, but when compiled with -O3 this always gives me a Seg Fault when run
(and probably invalid code more generally).
It may be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
[Bug fortran/64692] Incorrect result for sourced allocate of class(*) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692 --- Comment #2 from Antony Lewis antony at cosmologist dot info --- May be same/related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 ?
[Bug fortran/64678] Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 --- Comment #3 from Antony Lewis antony at cosmologist dot info --- Indeed, that's the easy workaround. I'd have thought the obvious definition for the single multi-associate statement would be to be a shortcut exactly equivalent to nested associates.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 Antony Lewis antony at cosmologist dot info changed: What|Removed |Added CC||antony at cosmologist dot info --- Comment #5 from Antony Lewis antony at cosmologist dot info --- Here's another example (giving 0 and 1 for lbound) program test double precision x,y x=3 y=4 call W([x,y]) !this gives wrong result (4,4) call W([3.d0,4.d0]) !this works (3,4) contains subroutine W(Ar) class(*), intent(in) :: Ar(:) print *, lbound(ar) select type (Ar) type is (double precision) print *,Ar(1:2) end select end subroutine end program
[Bug fortran/64692] New: Incorrect result for sourced allocate of class(*) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692
Bug ID: 64692
Summary: Incorrect result for sourced allocate of class(*)
array
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
The following code gives incorrect output in trunk ('array 1' and 'array 2'
should be the same):
module Y
contains
subroutine AddArray(P)
class(*), target, intent(in) :: P(:)
class(*), pointer :: Pt(:)
allocate(Pt(1:SIZE(P)), source= P)
select type (P)
type is (double precision)
print *,'array 1',P
end select
select type (Pt )
type is (double precision)
print *,'array 2',Pt
end select
end subroutine
end module Y
program test
use Y
double precision P(2,2)
P(1:2,1)=[1.d0,2.d0]
P(1:2,2) = [3.d0,4.d0]
call AddArray(P(1:2,2))
end program test
The select types are just there to show the output, they aren't needed for the
bug.
[Bug fortran/64678] New: Expected association error on dependent associate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678 Bug ID: 64678 Summary: Expected association error on dependent associate statements Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info In trunk module X Type T integer :: map end Type T contains subroutine DoBug Type(T) TT associate(A=TT, B=A%map) end associate end subroutine end module X gives: testbug.f90:10:17: associate(A=TT, B=A%map) 1 Error: Expected association at (1) testbug.f90:11:4: end associate 1 It's not entirely clear to me from the standard if this is allowed, but I don't see why not (useful when you are breaking up complicated array/class structures into associate names, where the second name refers to the first). It compiles in ifort. Obviously low priority as can be worked around easily enough
[Bug fortran/64674] New: OOP Internal compiler error in associate with allocated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 Bug ID: 64674 Summary: OOP Internal compiler error in associate with allocated class Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info On latest trunk module X Type T integer :: map end Type T contains subroutine DoBug class(T), allocatable :: Cls(:,:) allocate(T::Cls(2, 2)) associate(CL = Cls(1,2)) CL%map = 2 end associate end subroutine end module X gives testbug.f90:12:0: CL%map = 2 1 internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1954 0x82e588e gfc_conv_component_ref ../../gcc-trunk/gcc/fortran/trans-expr.c:1954 0x82ed630 gfc_conv_variable ../../gcc-trunk/gcc/fortran/trans-expr.c:2211 0x82eaea0 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-expr.c:6836 0x82f856d gfc_trans_assignment_1 ../../gcc-trunk/gcc/fortran/trans-expr.c:8568 0x82f9a75 gfc_trans_assign(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-expr.c:8765 0x82b836d trans_code ../../gcc-trunk/gcc/fortran/trans.c:1650 0x832b3f7 gfc_trans_block_construct(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-stmt.c:1456 0x82b80c8 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1755 0x82e1f55 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5843 0x82bc482 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:2021 0x82761ba translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:5328 0x82761ba gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:5538 0x82b436b gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:228 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. If you change class(T) to type(T) it compiles OK.
[Bug fortran/61275] New: Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275
Bug ID: 61275
Summary: Invalid initialization expression for ALLOCATABLE
component in structure constructor at (1)
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module A
Type T
character(LEN=:), allocatable :: S
end type
Type(T) :: TestObj = T('string')
contains
end module
Trunk gives
Error: Invalid initialization expression for ALLOCATABLE component 's' in
structure constructor at (1)
Note similarity to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976#c12
which was apparently working at some point. (but great to see deferred-length
character components of derived types now implemented).
[Bug fortran/60458] Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458 --- Comment #2 from Antony Lewis antony at cosmologist dot info --- Here's a related example: module A implicit none Type T integer :: val = 2 contains final :: testfree end type contains subroutine testfree(this) Type(T) this print *,'freed' end subroutine subroutine Testf() associate(X = T()) print *, X%val end associate print *,'after scope' end subroutine Testf end module which gives print *, X%val 1 Error: Symbol 'x' at (1) has no IMPLICIT type (I was checking if finalization is called correctly, but didn't get that far) This code compiles in ifort.
[Bug fortran/60458] Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458 --- Comment #4 from Antony Lewis antony at cosmologist dot info --- OK, will do. (thought the underlying cause might be same issue with associate variables)
[Bug fortran/60483] New: associate error on valid code: no IMPLICIT type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483 Bug ID: 60483 Summary: associate error on valid code: no IMPLICIT type Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info module A implicit none Type T integer :: val = 2 contains final :: testfree end type contains subroutine testfree(this) Type(T) this print *,'freed' end subroutine subroutine Testf() associate(X = T()) print *, X%val end associate print *,'after scope' end subroutine Testf end module which gives print *, X%val 1 Error: Symbol 'x' at (1) has no IMPLICIT type (code checks if finalization is called correctly, but didn't get that far) This code compiles in ifort.
[Bug fortran/60495] New: ICE: in fold_convert_loc, at fold-const.c:1994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495 Bug ID: 60495 Summary: ICE: in fold_convert_loc, at fold-const.c:1994 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info module A implicit none Type T contains final :: testfree end type Type, extends(T) :: T2 real, allocatable :: Y(:) class(T), allocatable :: XX contains end type contains subroutine testfree(this) Type(T) this end subroutine subroutine Testf() Type(T2) A, B B=A end subroutine end module TestClass.f90: In function ‘testf’: TestClass.f90:26:0: internal compiler error: in fold_convert_loc, at fold-const.c:1994 B=A ^ 0x83f3a5a fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc-trunk/gcc/fold-const.c:1993 0x8205f01 gfc_conv_descriptor_data_set(stmtblock_t*, tree_node*, tree_node*) ../../gcc-trunk/gcc/fortran/trans-array.c:178 0x822c5d2 gfc_conv_scalar_to_descriptor(gfc_se*, tree_node*, symbol_attribute) ../../gcc-trunk/gcc/fortran/trans-expr.c:74 0x820254d gfc_add_comp_finalizer_call(stmtblock_t*, tree_node*, gfc_component*, bool) ../../gcc-trunk/gcc/fortran/trans.c:1012 0x820f7d5 structure_alloc_comps ../../gcc-trunk/gcc/fortran/trans-array.c:7622 0x822fd85 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:6955 0x823acd0 gfc_trans_assignment_1 ../../gcc-trunk/gcc/fortran/trans-expr.c:7999 0x823e0d5 gfc_trans_assign(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-expr.c:8170 0x8201ffd trans_code ../../gcc-trunk/gcc/fortran/trans.c:1623 0x8229920 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5610 0x82036f2 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:1956 0x81c0df6 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4523 0x81c0df6 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4733 0x81fd035 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:188 Please submit a full bug report, with preprocessed source if appropriate.
[Bug fortran/60458] New: Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458 Bug ID: 60458 Summary: Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info module A Type T contains procedure :: Test procedure :: TestP end type contains subroutine test(this) class(T) this associate(S= this%TestP()) print *,S end associate end subroutine function TestP(this) class(T) this character(LEN=:), allocatable :: TestP TestP ='' end function TestP end module gives error associate(S= this%TestP()) 1 Error: Entity 's' at (1) has a deferred type parameter and requires either the pointer or allocatable attribute At best the error message is unhelpful (defining S with pointer attribute does not help), and the code seems valid (though it also happens to ICE ifort).
[Bug fortran/60414] New: internal compiler error: tree check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 Bug ID: 60414 Summary: internal compiler error: tree check Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info module testmod Type T contains procedure :: FWrite procedure :: FWriteArr generic :: Write = FWrite, FWriteArr end Type contains subroutine FWrite(this,X) class(T) this class(*) X end subroutine FWrite subroutine FWriteArr(this,X) class(T) this class(*) X(:) end subroutine FWriteARr subroutine WriteTextVector(aname, vec, n) character(LEN=*), intent(IN) :: aname integer, intent(in) :: n class(*), intent(in) :: vec(n) integer j Type(T) :: Tester j=1 call Tester%Write(vec(j)) end subroutine WriteTextVector end module gfortran -c TestClass.f90 TestClass.f90: In function ‘writetextvector’: TestClass.f90:33:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have pointer_type in gfc_class_data_get, at fortran/trans-expr.c:125 call Tester%Write(vec(j)) ^ 0x8809538 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc-trunk/gcc/tree.c:9192 0x822c9a4 tree_check3 ../../gcc-trunk/gcc/tree.h:2749 0x822c9a4 gfc_class_data_get(tree_node*) ../../gcc-trunk/gcc/fortran/trans-expr.c:125 0x823633a gfc_conv_class_to_class(gfc_se*, gfc_expr*, gfc_typespec, bool, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:668 0x823318c gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc-trunk/gcc/fortran/trans-expr.c:4258 0x825b86b gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc-trunk/gcc/fortran/trans-stmt.c:408 0x8202064 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1701 0x8229920 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5610 0x82036f2 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:1956 0x81c0df6 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4523 0x81c0df6 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4733 0x81fd035 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:188 Please submit a full bug report,
[Bug fortran/60334] Segmentation fault on character pointer assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 --- Comment #2 from Antony Lewis antony at cosmologist dot info --- I looked for a while for a reproducible crash, which wasn't easy - mostly behaviour was errratic crashes - I was using 4.9 trunk from a week ago. But there was definitely a general problem with the code generated by this kind of construct with various compiler options: a module full of them crashed all over the place or gave erratic results (compiled with gfortran, it's fine with ifort). It again worked fine when I changed all the character function results and temporary variables to allocatables. (my guess was the code is mistakenly auto-freeing some charater pointers in the same way it does character allocatables). Happy to provide the more realistic test case if useful to testing.
[Bug fortran/60255] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 --- Comment #5 from Antony Lewis antony at cosmologist dot info --- The patch generated a SIGSEGV in test code (which works with ifort), but could be another unrelated issue. Here's another simple test case for the original issue: program test character(LEN=:), allocatable :: S call subP(S) contains subroutine subP(P) class(*) :: P end subroutine end program
[Bug fortran/60357] New: structure constructor with unspecified values for allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 Bug ID: 60357 Summary: structure constructor with unspecified values for allocatable components Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info This valid F2008 code is rejected: module testmod Type A integer :: X = 1 integer, allocatable :: y end type A end module program testerprog use testmod Type(A) :: Me = A(X=1) end program Compiler error is: Type(A) :: Me = A(X=1) 1 Error: No initializer for component 'y' given in the structure constructor at (1)! However initialization statements are not required for allocatable components.
[Bug fortran/60359] New: Assembler messages symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 Bug ID: 60359 Summary: Assembler messages symbol `__io_MOD___copy_character_1' is already defined Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Created attachment 32226 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32226action=edit Source and makefile make getdist BUILD=NOMPI mkdir -p Release gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c MiscUtils.f90 -o Release/MiscUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c ArrayUtils.f90 -o Release/ArrayUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c StringUtils.f90 -o Release/StringUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c MpiUtils.f90 -o Release/MpiUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c FileUtils.f90 -o Release/FileUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c RandUtils.f90 -o Release/RandUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c ObjectLists.f90 -o Release/ObjectLists.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c Interpolation.f90 -o Release/Interpolation.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c IniObjects.f90 -o Release/IniObjects.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c ObjectParamNames.f90 -o Release/ObjectParamNames.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c settings.f90 -o Release/settings.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c Matrix_utils_new.f90 -o Release/Matrix_utils_new.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c samples.f90 -o Release/samples.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c IO.f90 -o Release/IO.o /tmp/cca4GMDL.s: Assembler messages: /tmp/cca4GMDL.s:102: Error: symbol `__io_MOD___copy_character_1' is already defined
[Bug fortran/60359] Assembler messages symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359
--- Comment #2 from Antony Lewis antony at cosmologist dot info ---
This was reduced already, but actually wasn't too hard to find something much
simpler- just this:
module IO
implicit none
contains
subroutine FWRite(S)
class(*) :: S
end subroutine FWrite
subroutine IO_OutputMargeStats()
character(LEN=128) tag
call FWrite(' '//tag)
call FWrite(' '//tag)
end subroutine IO_OutputMargeStats
end module IO
[Bug fortran/60334] New: Segmentation fault on character pointer assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 Bug ID: 60334 Summary: Segmentation fault on character pointer assignments Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info This compiles OK program tester implicit none character(LEN=:), pointer :: Y character(LEN=0), target :: Empty_String = '' Y = test() print *, Y contains function test() result(P) character(LEN=:), pointer :: P P= Empty_String end function end program but compiled with gfortran -Og when run gives Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + [0xb776c400] + /lib/i386-linux-gnu/libc.so.6(+0x13afcb) [0xb7529fcb] + in the main program from file TestClass.f90 + /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0xb74084d3] *** glibc detected *** ./a.out: free(): invalid pointer: 0x09be0898 *** Other compiler options don't so reliably crash, but still probably invalid code (I think). It's not specific to the string having zero length.
[Bug fortran/60289] New: allocating class(*) pointer as character gives type-spec requires the same character-length parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289 Bug ID: 60289 Summary: allocating class(*) pointer as character gives type-spec requires the same character-length parameter Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info class(*), pointer :: P allocate(character(5)::P) gives error Error: Allocating p at (1) with type-spec requires the same character-length parameter as in the declaration
[Bug fortran/60238] New: Allow colon-separated triplet in array initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60238 Bug ID: 60238 Summary: Allow colon-separated triplet in array initialization Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Not really a bug, but ifort (and also going back, CVF) allow a clean array initialization sytnax like this integer :: indices(3) indices=[3:5] as an alternative to the ugly indices = (/ (I, I=3, 5) /) Supporting it would allow easier compiler interoperability.
[Bug fortran/60255] New: Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 Bug ID: 60255 Summary: Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Created attachment 32157 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32157action=edit OOP module with derived TStringList implementing list of strings Attached file gives multiple repeated errors ObjectLists2.f90:818.26: end module ObjectLists 1 Error: TODO: Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities It should surely give a line number of the error rather than end of module (currently very hard to workaround as origin of error is unclear). Better, actually compile (tested valid in ifort 14).
[Bug fortran/60231] New: ICE on undefined generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60231 Bug ID: 60231 Summary: ICE on undefined generic Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info SampleTest.f90 containing module Objects Type TObjectList contains procedure :: Add1 procedure :: Add2 generic :: Add = Add1, Add2 end Type TObjectList end module Objects gives gfortran -c SampleTest.f90 f951: internal compiler error: Segmentation fault 0x85faaea crash_signal ../../gcc-trunk/gcc/toplev.c:337 0x81ca0a4 check_generic_tbp_ambiguity ../../gcc-trunk/gcc/fortran/resolve.c:11393 0x81ca24b resolve_tb_generic_targets ../../gcc-trunk/gcc/fortran/resolve.c:11482 0x81ca820 resolve_typebound_generic ../../gcc-trunk/gcc/fortran/resolve.c:11539 0x81ca820 resolve_typebound_procedure ../../gcc-trunk/gcc/fortran/resolve.c:11713 0x81ee7fa do_traverse_symtree ../../gcc-trunk/gcc/fortran/symbol.c:3581 0x81dd2c0 resolve_typebound_procedures ../../gcc-trunk/gcc/fortran/resolve.c:11910 0x81dd2c0 resolve_fl_derived ../../gcc-trunk/gcc/fortran/resolve.c:12519 0x81d82a6 resolve_symbol ../../gcc-trunk/gcc/fortran/resolve.c:12786 0x81ee7be do_traverse_symtree ../../gcc-trunk/gcc/fortran/symbol.c:3575 0x81db14d resolve_types ../../gcc-trunk/gcc/fortran/resolve.c:14491 0x81d706c gfc_resolve ../../gcc-trunk/gcc/fortran/resolve.c:14588 0x81c323f gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4672 0x81ff6c5 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:188 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.
[Bug fortran/60232] New: OOP False Error: The rank of the element in the structure constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60232 Bug ID: 60232 Summary: OOP False Error: The rank of the element in the structure constructor Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info module defining inherited class module Samples use ObjectLists implicit none Type, extends(TObjectList):: TSampleList contains procedure :: ConfidVal = TSampleList_ConfidVal end Type TSampleList contains subroutine TSampleList_ConfidVal(L) Class(TSampleList) :: L end subroutine TSampleList_ConfidVal end module Samples gives false compiler error: During initialization Error: The rank of the element in the structure constructor at (1) does not match that of the component (1/0) The code is valid and works in ifort (from CosmoMC package). The inherited ObjectLists module is available at http://gcc.gnu.org/bugzilla/attachment.cgi?id=31394 (I have not yet been able to make a shorter single-file test case but did try.)
[Bug fortran/60234] New: OOP internal compiler error: in generate_finalization_wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234 Bug ID: 60234 Summary: OOP internal compiler error: in generate_finalization_wrapper Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Created attachment 32146 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32146action=edit OOP module implementing lists of arrays of objects (with final) Problem module attached: gfortran -cpp -c ObjectLists.f90 f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1883 0x816b6d9 generate_finalization_wrapper ../../gcc-trunk/gcc/fortran/class.c:1883 0x816b6d9 gfc_find_derived_vtab(gfc_symbol*) ../../gcc-trunk/gcc/fortran/class.c:2315 0x8169eb7 gfc_find_derived_vtab(gfc_symbol*) ../../gcc-trunk/gcc/fortran/class.c:2188 0x816c347 gfc_build_class_symbol(gfc_typespec*, symbol_attribute*, gfc_array_spec**, bool) ../../gcc-trunk/gcc/fortran/class.c:646 0x8172438 build_sym ../../gcc-trunk/gcc/fortran/decl.c:1202 0x8177d1e variable_decl ../../gcc-trunk/gcc/fortran/decl.c:1980 0x8177d1e gfc_match_data_decl() ../../gcc-trunk/gcc/fortran/decl.c:4309 0x81bd5e7 match_word ../../gcc-trunk/gcc/fortran/parse.c:65 0x81be6ba match_word ../../gcc-trunk/gcc/fortran/parse.c:331 0x81be6ba decode_statement ../../gcc-trunk/gcc/fortran/parse.c:331 0x81bfac7 next_free ../../gcc-trunk/gcc/fortran/parse.c:784 0x81bfac7 next_statement ../../gcc-trunk/gcc/fortran/parse.c:977 0x81c0247 parse_spec ../../gcc-trunk/gcc/fortran/parse.c:2784 0x81c21f8 parse_progunit ../../gcc-trunk/gcc/fortran/parse.c:4148 0x81c2556 parse_contained ../../gcc-trunk/gcc/fortran/parse.c:4087 0x81c36ec parse_module ../../gcc-trunk/gcc/fortran/parse.c:4350 0x81c36ec gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4652 0x81ff6c5 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:188
[Bug fortran/59414] [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #5 from Antony Lewis antony at cosmologist dot info --- Thanks for the quick fix! The sourced allocate errors crop up in various places in the full code, and already seem to be known in several bug reports, e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 For example in this case you just get a compiler error: module test Type InterpGrid2D REAL, pointer :: z(:,:) = NULL() contains procedure :: Init = InterpGrid2D_Init end Type InterpGrid2D contains subroutine InterpGrid2D_Init(W, z) class(InterpGrid2D):: W REAL, INTENT(IN), pointer :: z(:,:) allocate(W%z, source = z) end subroutine InterpGrid2D_Init end module
[Bug fortran/59414] New: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 Bug ID: 59414 Summary: Class array pointers: compile error on valid code (Different ranks in pointer assignment) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Created attachment 31394 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31394action=edit OOP module implementing lists of arrays of objects Compiler errors like ObjectLists.f90:597.4: Item = L%ArrayItem(i) 1 Error: Different ranks in pointer assignment at (1) Code is a class array pointer to a function that returns a class array pointer: function ArrayItem(L, i) result(P) Class(TObjectList) :: L integer, intent(in) :: i Class(*), pointer :: P(:) select type (Point= L%Items(i)%P) class is (object_array_pointer) P = Point%P class default stop 'TObjectList: item is not array item' end select end function ArrayItem ... class(*), pointer :: Item(:) Item = L%ArrayItem(i) Code is valid and works with the Intel compiler. Complete generic list module attached (from the widely-used but currently not gfortran-compiling CosmoMC parameter estimation package).
[Bug fortran/35470] New: Valid pointer assigment code gives compilation errors
This code compiles fine on all other known f95 compilers but gives an error in gfortran (code compiled with __GFORTRAN__ works, alternative does not): type real_pointer real, dimension(:), pointer :: p end type real_pointer ... recursive subroutine QuickSortArr_Real(Arr, Lin, R, index) !Sorts an array of pointers to arrays of reals by the value of the index'th entry integer, intent(in) :: Lin, R, index #ifdef __GFORTRAN__ type(real_pointer), dimension(:) :: Arr #else type(real_pointer), dimension(*) :: Arr #endif integer I, J, L real P type(real_pointer) :: temp L = Lin do I = L J = R P = Arr((L + R)/2)%p(index) do do while (Arr(I)%p(index) P) I = I + 1 end do do while (Arr(J)%p(index) P) J = J - 1 end do if (I = J) then Temp%p = Arr(I)%p Arr(I)%p = Arr(J)%p Arr(J)%p = Temp%p I = I + 1 J = J - 1 end if if (I J) exit end do if (L J) call QuickSortArr_Real(Arr, L, J, index); L = I if (I = R) exit end do end subroutine QuickSortArr_Real -- Summary: Valid pointer assigment code gives compilation errors Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: antony at cosmologist dot info http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
