[Bug fortran/57833] New: MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57833 Bug ID: 57833 Summary: MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The following throws an error in both gfortran 4.8 and 4.9, and it shouldn't. module mod1 contains pure subroutine expand_array(array) character(*), allocatable, intent(INOUT) :: array(:) character(LEN(array)), allocatable :: aux(:) if (ALLOCATED(array)) then call MOVE_ALLOC(array, aux) allocate (array(SIZE(aux) + 1)) array(:SIZE(aux)) = aux deallocate (aux) else allocate (array(1)) endif end subroutine end module The actual output is: ...:~$ gfortran-4.9 -c test_move_alloc.f90 test_move_alloc.f90:11.27: allocate (array(SIZE(aux) + 1)) 1 Error: 'array' must not appear in the array specification at (1) in the same ALLOCATE statement where it is itself allocated The info for gfortran 4.8 and 4.9 is: ...:~$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v && apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd lrwxrwxrwx 1 root staff 34 Jul 5 12:58 /usr/local/bin/gfortran-4.9 -> /usr/lib/gcc-snapshot/bin/gfortran* Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20130620-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.0 20130620 (experimental) [trunk revision 200244] (Debian 20130620-1) gfortran-4.8: Installed: 4.8.1-5 Candidate: 4.8.1-5 Version table: *** 4.8.1-5 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status 4.8.1-2 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages gcc-snapshot: Installed: 20130620-1 Candidate: 20130620-1 Version table: *** 20130620-1 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status Description:Debian GNU/Linux testing (jessie) Release:testing
[Bug fortran/57834] New: C_F_POINTER regression(-std): accepts only explicit- and assumed-size arrays for FPTR when SHAPE is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57834 Bug ID: 57834 Summary: C_F_POINTER regression(-std): accepts only explicit- and assumed-size arrays for FPTR when SHAPE is present Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The following compiles with gfortran 4.8, but fails with gfortran 4.9: program main use iso_c_binding use iso_fortran_env implicit none interface function strerror(errno) bind(C, NAME = 'strerror') import type(C_PTR) :: strerror integer(C_INT), value :: errno end function end interface integer :: i type(C_PTR) :: cptr character(KIND=C_CHAR), pointer :: str(:) cptr = strerror(INT(42, KIND = C_INT)) call C_F_POINTER(cptr, str, [255]) do i = 1, SIZE(str) if (str(i) == C_NULL_CHAR) exit write (ERROR_UNIT, '(A1)', ADVANCE = 'NO') str(i:i) enddo write (ERROR_UNIT, '(1X)') end program main The actual error, which only happens when -std=f2003 or -std=f2008 is used, is highly inconsistent: FPTR must be pointer and when SHAPE is present, it must also be a deferred-shape array one. The error is: ...:~$ gfortran-4.9 -std=f2008 test_cfpointer.f90 test_cfpointer.f90:21.27: call C_F_POINTER(cptr, str, [255]) 1 Error: TS 29113: Noninteroperable array FPTR at (1) to C_F_POINTER: Only explicit-size and assumed-size arrays are interoperable The system info is: ...:~$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v && apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd lrwxrwxrwx 1 root staff 34 Jul 5 12:58 /usr/local/bin/gfortran-4.9 -> /usr/lib/gcc-snapshot/bin/gfortran* Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20130620-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.0 20130620 (experimental) [trunk revision 200244] (Debian 20130620-1) gfortran-4.8: Installed: 4.8.1-5 Candidate: 4.8.1-5 Version table: *** 4.8.1-5 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status 4.8.1-2 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages gcc-snapshot: Installed: 20130620-1 Candidate: 20130620-1 Version table: *** 20130620-1 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status Description:Debian GNU/Linux testing (jessie) Release:testing
[Bug fortran/57839] New: Reallocate on assignment does not work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57839 Bug ID: 57839 Summary: Reallocate on assignment does not work properly Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The following program does not produce the expected results with either gfortran 4.8 or gfortran 4.9: program test_lhs_allocate use iso_fortran_env implicit none type :: table character(63) :: name = '' character(63), allocatable :: alias(:) end type integer :: i, j type(table), allocatable :: list(:) type(table) :: item allocate (list(1:0))!empty list item%name = 'name' item%alias = [character(63) :: 'label'] list = [list, item] item%name = 'id' item%alias = [character(63) :: ] list = [list, item] item%name = 'status' item%alias = [character(63) :: 'state', 'validity', 'test'] list = [list, item] !item%name = 'other' !item%alias = [character(63) :: 'extra', 'additional', 'more'] !list = [list, item] do i = 1, SIZE(list) write (OUTPUT_UNIT, '(/"name: ", A,/,"aliases: ", *(A,:,","))') & TRIM(list(i)%name), & (TRIM(list(i)%alias(j)), j = 1, SIZE(list(i)%alias)) enddo end program test_lhs_allocate The actual output is: ...:~$ gfortran-4.9 -std=f2008 test_lhs_allocate.f90 ...:~$ ./a.out name: name aliases: ��� name: id aliases: name: status aliases: state,validity,test What is expected: name: name aliases: label name: id aliases: name: status aliases: state,validity If I enable the three commented lines, then the output is: ...:~$ gfortran-4.9 -std=f2008 test_lhs_allocate.f90 ...:~$ ./a.out name: name aliases: ��� name: id aliases: name: status aliases: name,���id, � name: other aliases: extra,additional,more It seems as if every time an item is added to the list, all the aliases in the previous items are lost. The system information is: ...:~$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v && apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd lrwxrwxrwx 1 root staff 34 Jul 5 12:58 /usr/local/bin/gfortran-4.9 -> /usr/lib/gcc-snapshot/bin/gfortran* Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20130620-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.0 20130620 (experimental) [trunk revision 200244] (Debian 20130620-1) gfortran-4.8: Installed: 4.8.1-5 Candidate: 4.8.1-5 Version table: *** 4.8.1-5 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status 4.8.1-2 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages gcc-snapshot: Installed: 20130620-1 Candidate: 20130620-1 Version table: *** 20130620-1 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status Description:Debian GNU/Linux testing (jessie) Release:testing
[Bug fortran/57843] New: Polymorphic assignment for derived type is resolved with parent's generic instead of its own
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57843 Bug ID: 57843 Summary: Polymorphic assignment for derived type is resolved with parent's generic instead of its own Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The code below does not do what's expected when compiled with gfortran-4.9 (i.e., to print "this is right" instead of "what am I doing here?" every time the polymorphic assignment is invoked, and also printing the assigned values at the end, instead of the default ones. Maybe I still don't understand the semantics behind Fortran 2003+'s type-bound assignment (so I apologize in advance if this is not a bug), but it seems to me that the assign_itemType procedure is being used for assignment, even though it doesn't satisfy the requirement of exact type for the "right" argument ---is polymorphism being resolved at compile time even for dynamic cases? By commenting out the line marked with "!*", I get an ICE with ifort 13.1.3, so I have no way to compare behavior. !-test_assign.f90 module mod1 implicit none type :: itemType contains procedure :: assign_itemType generic :: assignment(=) => assign_itemType end type type, abstract :: tableType class(itemType), allocatable :: table(:) contains procedure :: process procedure(i_setItem), nopass, deferred :: setItem end type abstract interface subroutine i_setItem(array, item) import character(*), intent(IN) :: array(:) class(itemType), allocatable, intent(OUT) :: item end subroutine end interface contains subroutine process(this) class(tableType), intent(INOUT) :: this integer :: i, j, n character(5), allocatable :: array(:) class(itemType), allocatable :: item, aux(:) do i = 1, 3 print '(/,"item ",I0)', i array = [character(5) :: 'abc', '1', '12.3'] call this%setItem(array, item) if (ALLOCATED(this%table)) then n = SIZE(this%table) call MOVE_ALLOC(this%table, aux) allocate (this%table(n+1), MOLD = item) print *, 'table is same type as aux?:', & SAME_TYPE_AS(this%table, aux) do j = 1, n this%table(j) = aux(j) enddo this%table(n+1) = item else allocate (this%table(1), SOURCE = item) endif print *, 'table is same type as item?:', & SAME_TYPE_AS(this%table, item) print *, 'table is same type as itemType?:', & SAME_TYPE_AS(this%table, itemType())!* print *, 'table extends type itemType?:', & EXTENDS_TYPE_OF(this%table, itemType()) enddo end subroutine subroutine assign_itemType(left, right) class(itemType), intent(OUT) :: left type(itemType), intent(IN) :: right print *, 'what am I doing here?' end subroutine end module mod1 module mod2 use mod1 implicit none type, extends(itemType) :: myItem character(3) :: name = '' integer :: num = 0 real :: val = 0 contains procedure :: assign_myItem generic :: assignment(=) => assign_myItem end type type, extends(tableType) :: myTable contains procedure, nopass :: setItem procedure :: output end type contains subroutine setItem(array, item) character(*), intent(IN) :: array(:) class(itemType), allocatable, intent(OUT) :: item allocate (myItem :: item) select type (item) type is (myItem) print *, 'setting...' item%name = array(1) read (array(2), *) item%num read (array(3), *) item%val end select end subroutine subroutine assign_myItem(left, right) class(myItem), intent(OUT) :: left type(myItem), intent(IN) :: right print *, 'this is right' left%name = right%name left%num = right%num left%val = right%val end subroutine subroutine output(this) class(myTable), intent(IN) :: this integer :: i do i = 1, SIZE(this%table) select type (item => this%table(i)) type is (myItem) print *, i, item%name, item%num, item%val
[Bug fortran/58185] New: ICE when selector in SELECT TYPE is non-polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58185 Bug ID: 58185 Summary: ICE when selector in SELECT TYPE is non-polymorphic Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com With gfortran 4.8/4.9, I get an ICE for the following (invalid) code: module mod1 implicit none save contains subroutine dosomething(array) !class(*), intent(IN) :: array integer, intent(IN) :: array select type (a => array) type is (integer) type is (real) class default stop end select end subroutine end module Bug #54435 seems similar, but is marked as fixed. System information follows: ...:~$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v && apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd lrwxrwxrwx 1 root staff 35 Aug 17 21:16 /usr/local/bin/gfortran-4.9 -> ../../lib/gcc-snapshot/bin/gfortran* Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20130731-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.0 20130731 (experimental) [trunk revision 201378] (Debian 20130731-1) gfortran-4.8: Installed: 4.8.1-9 Candidate: 4.8.1-9 Version table: *** 4.8.1-9 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status 4.8.1-2 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages gcc-snapshot: Installed: 20130731-1 Candidate: 20130731-1 Version table: *** 20130731-1 0 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status Description:Debian GNU/Linux testing (jessie) Release:testing
[Bug fortran/58229] New: Memory leak with overloaded operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229 Bug ID: 58229 Summary: Memory leak with overloaded operator Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The following, reduced version of the actual code (sorry if it's still too big), leaks memory quite fast when compiled with gfortran 4.8/4.9: !gfortran-4.9 -o test_leak ~/test_leak.f90 module mod1 implicit none type :: pointtype real :: x = 0, y = 0, z = 0 end type interface operator(*) module procedure point_times_scalar module procedure scalar_times_point end interface contains elemental function point_times_scalar(point, scalar) result(res) !type(pointtype) :: res type(pointtype), allocatable :: res type(pointtype), intent(IN) :: point real, intent(IN) :: scalar res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar) end function elemental function scalar_times_point(scalar, point) result(res) !type(pointtype) :: res type(pointtype), allocatable :: res real, intent(IN) :: scalar type(pointtype), intent(IN) :: point res = point * scalar end function end module mod1 use mod1 implicit none integer :: i, j real :: x(3) type(pointtype), allocatable :: a(:,:) allocate (a(100,100)) do j = 1, SIZE(a,2) do i = 1, SIZE(a, 1) call RANDOM_NUMBER(x) a(i,j) = pointtype(x(1), x(2), x(3)) a(i,j) = 2. * a(i,j) a(i,j) = 3. * a(i,j) a(i,j) = 4. * a(i,j) enddo enddo end Version 4.9 seems to be leaking more memory than version 4.8. Valgrind's output is: ==10718== Memcheck, a memory error detector ==10718== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==10718== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==10718== Command: ./test_leak ==10718== Parent PID: 31089 ==10718== --10718-- --10718-- Valgrind options: --10718----suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp --10718---v --10718----log-file=./valgrind.log --10718----num-callers=100 --10718----leak-check=full --10718----undef-value-errors=no --10718-- Contents of /proc/version: --10718-- Linux version 3.10-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.5-1 (2013-08-07) --10718-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt --10718-- Page sizes: currently 4096, max supported 4096 --10718-- Valgrind library directory: /usr/lib/valgrind --10718-- Reading syms from /tmp/test_leak --10718-- Reading syms from /lib/x86_64-linux-gnu/ld-2.17.so --10718-- Considering /lib/x86_64-linux-gnu/ld-2.17.so .. --10718-- .. CRC mismatch (computed 1a41d356 wanted 031d690d) --10718-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so .. --10718-- .. CRC is valid --10718-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux --10718-- Considering /usr/lib/valgrind/memcheck-amd64-linux .. --10718-- .. CRC mismatch (computed 5a0963b7 wanted f2a7ec16) --10718-- Considering /usr/lib/debug/usr/lib/valgrind/memcheck-amd64-linux .. --10718-- .. CRC is valid --10718--object doesn't have a dynamic symbol table --10718-- Scheduler: using generic scheduler lock implementation. --10718-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp --10718-- Reading suppressions file: /usr/lib/valgrind/default.supp ==10718== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-10718-by-jwm-on-??? ==10718== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-10718-by-jwm-on-??? ==10718== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-10718-by-jwm-on-??? ==10718== ==10718== TO CONTROL THIS PROCESS USING vgdb (which you probably ==10718== don't want to do, unless you know exactly what you're doing, ==10718== or are doing some strange experiment): ==10718== /usr/lib/valgrind/../../bin/vgdb --pid=10718 ...command... ==10718== ==10718== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==10718== /path/to/gdb ./test_leak ==10718== and then give GDB the following command ==10718== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=10718 ==10718== --pid is optional if only one valgrind process is running ==10718== --10718-- REDIR: 0x4017870 (strlen) redirected to 0x3806e381 (vgPlain_amd64_linux_REDIR_FOR_strlen) --10718-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so --10718-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --10718-- .. CRC mismatch (computed 2f3ef0a4 wanted fa342ee8) --10718-- Considering /usr/lib/debug/usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --10718-- .. CRC is valid --10718-- Readi
[Bug fortran/69739] New: ICE during array result, allocatable assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739 Bug ID: 69739 Summary: ICE during array result, allocatable assignment Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Target Milestone: --- Hi. With the code below I get an ICE with both GFortran 5 and 6. !- module test implicit none private save type, public :: sometype real :: a= 0. end type contains function dosomething(A) & result(res) real :: res type(sometype), intent(IN) :: A(:,:,:) integer :: N real, allocatable :: R(:), X(:) N = PRODUCT(UBOUND(A)) allocate (R(N), X(N)) X = 0 R = operate(A, X) !R(:) = operate(A, X) res = HUGE(1.) end function function operate(A, X) type(sometype), intent(IN) :: A(:,:,:) real, intent(IN) :: X(:) real :: operate(1:PRODUCT(UBOUND(A))) operate = 0 end function end module test !- Adding (:) to the array (as shown in the commented line) makes the ICE go away, so it seems there's an issue with assignment to an allocatable variable. The output was: ~$ gfortran-5 -c test.f90 test.f90:20:0: R = operate(A, X) 1 internal compiler error: in gfc_map_intrinsic_function, at fortran/trans-expr.c:3926 0x659661 gfc_map_intrinsic_function ../../src/gcc/fortran/trans-expr.c:3926 0x659661 gfc_apply_interface_mapping_to_expr ../../src/gcc/fortran/trans-expr.c:4056 0x65945a gfc_apply_interface_mapping_to_expr ../../src/gcc/fortran/trans-expr.c:4051 0x65763c gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) ../../src/gcc/fortran/trans-expr.c:4091 0x63c202 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) ../../src/gcc/fortran/trans-array.c:794 0x651dd5 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../src/gcc/fortran/trans-expr.c:5624 0x64c32d gfc_trans_arrayfunc_assign ../../src/gcc/fortran/trans-expr.c:8433 0x64bb34 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool) ../../src/gcc/fortran/trans-expr.c:9244 0xd4c910 trans_code ../../src/gcc/fortran/trans.c:1701 0xd4c910 gfc_trans_code(gfc_code*) ../../src/gcc/fortran/trans.c:2005 0xd51328 gfc_generate_function_code(gfc_namespace*) ../../src/gcc/fortran/trans-decl.c:5851 0x62db67 gfc_generate_module_code(gfc_namespace*) ../../src/gcc/fortran/trans.c:2072 0xd2f0ca translate_all_program_units ../../src/gcc/fortran/parse.c:5330 0xd2f0ca gfc_parse_file() ../../src/gcc/fortran/parse.c:5540 0x1200555 gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:229 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. ~$ gfortran-6 -c test.f90 test.f90:20:0: R = operate(A, X) internal compiler error: in gfc_map_intrinsic_function, at fortran/trans-expr.c:4089 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The OS and compiler versions are: $ lsb_release -rd && gfortran-5 -v && gfortran-6 -v Description:Debian GNU/Linux testing-updates (sid) Release:testing-updates Using built-in specs. COLLECT_GCC=gfortran-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-7' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.3.1 20160121 (Debian 5.3.1-7) Using built-in specs. COLLECT_GCC=gfor
[Bug fortran/69739] [4.9/5/6 Regression] ICE during array result, allocatable assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739 --- Comment #2 from John --- After reporting the bug, I noticed that in the actual code I have (not the reduced version I posted before), adding the (:) stride doesn't always make the ICE go away. What solved the problem once and for all (and without using the -fno-realloc-lhs flag) was changing the result in the "operate" function to be that of an allocatable array: function operate(A, X) type(sometype), intent(IN) :: A(:,:,:) real, intent(IN) :: X(:) !real :: operate(1:PRODUCT(UBOUND(A))) real, allocatable :: operate(:) allocate (operate(1:PRODUCT(UBOUND(A operate(:) = 0 end function So maybe the automatic-size result is the actual root of the ICE?
[Bug fortran/69870] New: ICE while detecting undeclared parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69870 Bug ID: 69870 Summary: ICE while detecting undeclared parameter Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Target Milestone: --- Hi. The (invalid) code below throws an ICE with both gfortran 5 and 6. - module somemod implicit none contains subroutine output() character(STRING_TEXT) :: msg end subroutine end module somemod - With gfortran 5 I get: ~$ gfortran-5 -c somemod.f90 somemod.f90:4:0: subroutine output() 1 internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1084 0x683cc8 gfc_typenode_for_spec(gfc_typespec*) ../../src/gcc/fortran/trans-types.c:1084 0x683cc8 gfc_sym_type(gfc_symbol*) ../../src/gcc/fortran/trans-types.c:2170 0xd4f548 gfc_get_symbol_decl(gfc_symbol*) ../../src/gcc/fortran/trans-decl.c:1511 0xd4e482 generate_local_decl ../../src/gcc/fortran/trans-decl.c:5055 0x64bce2 expr_decls ../../src/gcc/fortran/trans-decl.c:5003 0x5c4294 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../src/gcc/fortran/expr.c:4161 0x645a0b generate_expr_decls ../../src/gcc/fortran/trans-decl.c:5010 0x645a0b generate_dependency_declarations ../../src/gcc/fortran/trans-decl.c:5025 0x645a0b generate_local_decl ../../src/gcc/fortran/trans-decl.c:5052 0xd4405e do_traverse_symtree ../../src/gcc/fortran/symbol.c:3646 0xd4ce0b generate_local_vars ../../src/gcc/fortran/trans-decl.c:5245 0xd4ce0b gfc_generate_function_code(gfc_namespace*) ../../src/gcc/fortran/trans-decl.c:5781 0x62dd77 gfc_generate_module_code(gfc_namespace*) ../../src/gcc/fortran/trans.c:2072 0xd2afea translate_all_program_units ../../src/gcc/fortran/parse.c:5330 0xd2afea gfc_parse_file() ../../src/gcc/fortran/parse.c:5540 0x11e9fa5 gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:229 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. With gfortran 6 I get: ~$ gfortran-6 -c somemod.f90 somemod.f90:4:0: subroutine output() internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1064 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Ironically, removing the "implicit none" line shows the actual issue ---since STRING_TEXT becomes an implicitly REAL parameter/expression. System and compiler information follows: ~$ lsb_release -rd && gfortran-5 -v && gfortran-6 -v Description:Debian GNU/Linux testing-updates (sid) Release:testing-updates Using built-in specs. COLLECT_GCC=gfortran-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-8' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.3.1 20160205 (Debian 5.3.1-8) Using built-in specs. COLLECT_GCC=gfortran-6 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/6.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20160125-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmp
[Bug fortran/65381] New: ICE during array result, assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381 Bug ID: 65381 Summary: ICE during array result, assignment Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com I get Internal Compiler Error with the following code: module stringtable_mod implicit none private save type, public :: StringList character(:), allocatable :: chars end type type, public :: StringTable type(StringList), allocatable :: list(:) end type contains pure function fixedStringTable(this) result(fixed) class(StringTable), intent(IN) :: this(:) character(LEN_MAX(this)) :: fixed(getTableSize(this)) integer :: i, j, k k = 0 do i = 1, SIZE(this) if (.NOT. ALLOCATED(this(i)%list)) cycle do j = 1, SIZE(this(i)%list) k = k + 1 fixed(k) = this(i)%list(j)%chars enddo enddo end function pure function joinStrings(this) result(joined) character(:), allocatable :: joined type(StringTable), intent(IN) :: this(:) integer :: ln, sz character(:), allocatable :: strings(:) ln = LEN_MAX(this) sz = getTableSize(this) allocate (character(ln) :: strings(sz)) strings(:) = fixedStringTable(this) joined='' end function pure function LEN_MAX(this) result(stringlen) integer :: stringlen type(StringTable), intent(IN) :: this(:) integer :: i, j stringlen = 0 end function pure function getTableSize(this) result(sz) integer :: sz type(StringTable), intent(IN) :: this(:) integer :: i sz = 0 end function end module stringtable_mod The output is: $ gfortran-5.0 -c stringtable.f90 stringtable.f90:38:0: strings(:) = fixedStringTable(this) ^ internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1797 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The compiler and system information is: $ lsb_release -rd && gfortran-5.0 -v Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150225-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150225 (experimental) [trunk revision 220970] (Debian 20150225-1)
[Bug fortran/65541] New: namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 Bug ID: 65541 Summary: namelist regression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Version 5.0 of the gfortran runtime cannot read the namelist in the file that was generated by the code below, using gfortran 4.9. The opposite also holds (i.e., the runtime of version 4.9 cannot read a namelist generated by version 5.0). use ISO_FORTRAN_ENV implicit none type :: t1 integer :: i = 0 end type type, extends(t1) :: t2 integer :: j = 0 end type type, extends(t2) :: t3 integer :: k = 0 end type integer :: lu, ios character(255) :: msg type(t3) :: a namelist/some/a !open (newunit = lu, file = 'some.dat', status = 'OLD', access = 'SEQUENTIAL', action = 'READ', & open (newunit = lu, file = 'some.dat', status = 'REPLACE', access = 'SEQUENTIAL', action = 'WRITE', & position = 'REWIND', iostat = ios, iomsg = msg) if (ios /= 0) goto 100 !read (lu, some, IOSTAT = ios, IOMSG = msg) write (lu, some, IOSTAT = ios, IOMSG = msg) if (ios /= 0) goto 100 close (lu) stop 100 continue write (ERROR_UNIT, '(A)') TRIM(msg) stop 1 end The output generated by gfortran 4.9 is: $ ll `which gfortran` lrwxrwxrwx 1 root root 12 Feb 25 07:13 /usr/bin/gfortran -> gfortran-4.9* $ gfortran test_namelist.f90 $ ./a.out $ cat some.dat &SOME A%T2%T1%I= 0, A%T2%J= 0, A%K= 0, / The output generated by gfortran 5.0 is: $ ll `which gfortran-5.0` lrwxrwxrwx 1 root staff 35 Feb 26 11:01 /usr/local/bin/gfortran-5.0 -> ../../lib/gcc-snapshot/bin/gfortran* $ gfortran-5.0 test_namelist.f90 $ ./a.out $ cat some.dat &SOME A+T2+T1%I= 0, A+T2+J= 0, A+K= 0, / I hope that's not the intended behavior, since it makes namelists generated by gfortran incompatible with those generated by every other Fortran compiler. System and compiler information follows: $ lsb_release -rd && apt-cache policy gfortran && gfortran -v && gfortran-5.0 -v Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 gfortran: Installed: 4:4.9.2-2 Candidate: 4:4.9.2-2 Version table: 4:5-3 0 101 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages *** 4:4.9.2-2 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages 200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150319-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64/jre --enable-java-home
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #8 from John --- Hi, It seems that some testing was required after all. With the latest gcc snapshot from Debian (20150329-1) I still get the same output from the test code: $ ll `which gfortran-5.0 ` lrwxrwxrwx 1 root staff 35 Feb 26 11:01 /usr/local/bin/gfortran-5.0 -> ../../lib/gcc-snapshot/bin/gfortran* $ gfortran-5.0 test_namelist.f90 $ ./a.out $ cat some.dat &SOME A+T2+T1%I= 0, A+T2+J= 0, A+K= 0, / In my actual code, what fails is READING a namelist generated by a previous version of gfortran, so maybe that needs some checking as well? System and compiler information follows: $ lsb_release -rd && gfortran-5.0 -v Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150329-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150329 (experimental) [trunk revision 221764] (Debian 20150329-1)
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #11 from John --- Yes, -static does the trick when it comes to the namelist ---although, in the actual program, I get an obscure error when I try to invoke C's execv/waitpid. Thanks a lot for the help provided, and sorry for the inconvenience.
[Bug fortran/65677] New: Incomplete assignment on deferred-length character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 Bug ID: 65677 Summary: Incomplete assignment on deferred-length character variable Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The code below fails to produce the expected results. module mod1 implicit none contains subroutine getKeyword(string, keyword, rest) character(:), allocatable, intent(IN) :: string character(:), allocatable, intent(OUT) :: keyword, rest integer :: idx character(:), allocatable :: text keyword = '' rest = '' text = string text = ADJUSTL(text(2:))!*** idx = INDEX(text, ' ') if (idx == 0) then keyword = TRIM(text) else keyword = text(:idx-1) rest = TRIM(ADJUSTL(text(idx+1:))) endif end subroutine end module mod1 use mod1 implicit none character(:), allocatable :: line, keyword, rest line = '@HEREIT IS' call getKeyword(line, keyword, rest) print *, 'line: ', line print *, 'keyword: ', keyword print *, 'rest: ', rest end It seems that whenever a deferred-length character variable that's being assigned something is also a substring in the right-hand side expression, assignment is wrong/incomplete. The offending line is marked with "!***" in the code. This is the output I get: ~$ ll `which gfortran-5.0` lrwxrwxrwx 1 root staff 35 Feb 26 11:01 /usr/local/bin/gfortran-5.0 -> ../../lib/gcc-snapshot/bin/gfortran* ~$ gfortran-5.0 test_deferred.f90 ~$ ./a.out line: @HEREIT IS keyword: HERE rest: IT I So far I've noticed the error occurs only when the substring does not coincide with the beginning of the string. I get the same error with gfortran 4.9. The system and compiler information is: $ lsb_release -rd && gfortran-5.0 -v Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150404-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150404 (experimental) [trunk revision 221867] (Debian 20150404-1)
[Bug fortran/65223] New: Regresion on elemental type-bound procedure's passed object with INTENT(OUT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65223 Bug ID: 65223 Summary: Regresion on elemental type-bound procedure's passed object with INTENT(OUT) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The code below compiles just fine with gfortran 4.9, but throws an error with gfortran 5.0: module storage_mod implicit none private save type, public :: StorageClass character(20) :: name = 'default' contains procedure :: destroy => destroyStorage end type contains elemental subroutine destroyStorage(this) class(StorageClass), intent(OUT) :: this end subroutine end module storage_mod The output I get is: $ ll `which gfortran` lrwxrwxrwx 1 root root 12 Oct 18 04:03 /usr/bin/gfortran -> gfortran-4.9* $ gfortran -c storage_mod.f90 $ gfortran-5.0 -c storage_mod.f90 storage_mod.f90:12:44: elemental subroutine destroyStorage(this) 1 Error: INTENT(OUT) argument 'this' of pure procedure 'destroystorage' at (1) may not be polymorphic The error goes away by removing the ELEMENTAL attribute, so it seems like a regression on valid code. The compiler and system information is: $ lsb_release -rd Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 $ gfortran-5.0 -v Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150211-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5.0-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150211 (experimental) [trunk revision 220605] (Debian 20150211-1)
[Bug fortran/65223] Regresion on elemental type-bound procedure's passed object with INTENT(OUT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65223 --- Comment #2 from John --- Changing the ELEMENTAL attribute to PURE produces the same error. If that's the intended behavior, then that's the same as saying type-bound procedures cannot be pure. The thread mentioned by Dominique d'Humieres seems to only apply to "unlimited polymorphic", which is not part of the test case I posted.
[Bug fortran/63494] New: internal compiler error: Bus error, and out of memory allocating ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494
Bug ID: 63494
Summary: internal compiler error: Bus error, and out of memory
allocating ...
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jwmwalrus at gmail dot com
With the code below I get two errors while compiling. One with the
preprocessor, and one without.
module my_lrstring
implicit none
private
save
type :: lrStringType
character(:), allocatable :: left
character(:), allocatable :: right
end type
type, public :: lrString
type(lrStringType), allocatable, private :: storage(:)
contains
procedure :: getRight
end type
contains
pure function getRight(this, left) result(right)
character(:), allocatable :: right
class(lrString), intent(IN) :: this
character(*), intent(IN) :: left
integer :: i, j
character(:), allocatable :: text
right = ''
j = INDEX(this%storage(i)%right, '{}')
text = this%storage(i)%right(j+2:)
end function
end module my_lrstring
The output I get is:
$ gfortran-5.0 -c -g -x f95-cpp-input -Dmy_lrstring=my_lrstring_dbg
my_lrstring.f90
f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gfortran -c -g my_lrstring.f90
f951: out of memory allocating 20501133024 bytes after a total of 692224 bytes
The compiler and system information is:
$ lsb_release -rd
Description:Debian GNU/Linux testing (jessie)
Release:testing
$ gfortran-5.0 -v
Using built-in specs.
COLLECT_GCC=gfortran-5.0
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20140903-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5.0-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--disable-werror --enable-checking=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.0.0 20140904 (experimental) [trunk revision 214924] (Debian
20140903-1)
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31147
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31147
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[Bug fortran/62242] New: ICE with character function in expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 Bug ID: 62242 Summary: ICE with character function in expression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Hi, When trying to compile the following code: module gfbug implicit none save contains pure function UpperCase(string) result(upper) character(*), intent(IN) :: string character(LEN(string)) :: upper integer :: i, j upper = string do i = 1, LEN_TRIM(upper) j = IACHAR(upper(i:i)) select case (j) case (97:122) upper(i:i) = ACHAR(j - 32) case default end select enddo end function pure function isNotElementOf(scalar, array) result(status) logical :: status character(*), intent(IN) :: scalar, array(:) integer :: i status = .NOT. ANY(UpperCase(scalar) == [(UpperCase(array(i)), & i = 1, SIZE(array))]) end function end module gfbug I get the following output: $ /usr/lib/gcc-snapshot/bin/gfortran -c ./gfbug.f90 ./gfbug.f90: In function 'uppercase': ./gfbug.f90:10:0: internal compiler error: in expand_expr_real_1, at expr.c:9492 upper = string ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The UpperCase function is not really the issue, but its usage within the isNotElementOf function. Removing the PURE attribute does not affect the outcome. The ifort and sunf95 compilers handle the code just fine. Tested with both gfortran 4.9 and the 20140814 GCC snapshot: $ lsb_release -rd Description:Debian GNU/Linux testing (jessie) Release:testing $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.1 (Debian 4.9.1-4) $ /usr/lib/gcc-snapshot/bin/gfortran -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20140814-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.10-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.10-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.10-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.10.0 20140814 (experimental) [trunk revision 213954] (Debian 20140814-1)
[Bug fortran/49110] New: Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
Summary: Deferred-length character result triggers (false
positive) error for pure procedures
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jwmwal...@gmail.com
The use of a deferred-length character variable as a function result triggers a
(false positive) error for pure procedures. For example, the following module:
module mod1
use iso_c_binding
implicit none
contains
pure function c2fstring(cbuffer) result(string)
character(:), allocatable :: string
character(KIND = C_CHAR), intent(IN) :: cbuffer(:)
integer :: i
continue
string = REPEAT(' ', SIZE(cbuffer))
do i = 1, SIZE(cbuffer)
if (cbuffer(i) == C_NULL_CHAR) exit
string(i:i) = cbuffer(i)
enddo
string = TRIM(string)
end function
end module mod1
When compiled, the error thrown is:
...:~$ gfortran -c test_gfortran_pure.f90
test_gfortran_pure.f90:4.4:
pure function c2fstring(cbuffer) result(string)
1
Error: CHARACTER(*) function 'c2fstring' at (1) cannot be pure
The module compiles just fine with ifort v12.0.4 (command line: ifort -c -stand
test_gfortran_pure.f90).
The version information is:
...:~$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.6.0-3~ppa1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 20110409 (prerelease) (Ubuntu 4.6.0-3~ppa1)
The system information (for Ubuntu 11.04) is:
...:~$ uname -srvmpio
Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
[Bug fortran/49111] New: Unnecessary warning for private interfaces having the BIND(C) attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111 Summary: Unnecessary warning for private interfaces having the BIND(C) attribute Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jwmwal...@gmail.com When the following module: module mod1 use iso_c_binding implicit none save interface function strerror(errnum) bind(C, NAME = 'strerror') import type(C_PTR) :: strerror integer(C_INT), value :: errnum end function end interface private strerror end module mod1 gfortran warns about the private symbol 'strerror' being given a binding label. The exact warning is: ...:~$ gfortran -c test_gfortran_private_cbinding.f90 test_gfortran_private_cbinding.f90:8.8: function strerror(errnum) bind(C, NAME = 'strerror') 1 Warning: Symbol 'strerror' at (1) is marked PRIVATE but has been given the binding label 'strerror' In sections 5.3.2 and 5.3.5 of the Fortran 2008 standard, there seems to be no restriction between the BIND and PRIVATE attributes ---i.e., the BIND(C) attribute is compatible with the PRIVATE attribute, and therefore no warning should be issued by the gfortran. The version information is: ...:~$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.6.0-3~ppa1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 20110409 (prerelease) (Ubuntu 4.6.0-3~ppa1) The system information (for Ubuntu 11.04) is: ...:~$ uname -srvmpio Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/49112] New: Missing type-bound procedure, "duplicate save" warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 Summary: Missing type-bound procedure, "duplicate save" warnings and internal compiler error Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jwmwal...@gmail.com When I compile the following module: module datetime_mod implicit none private save type, public :: DateTime integer :: year = 0, month = 0, day = 0, hh = 0, mm = 0, ss = 0, & sss = 0 contains procedure :: getString procedure :: getDateString procedure :: getTimeString procedure, private :: getFormattedString end type type(DateTime), parameter :: & !*** ISO_REFERENCE_DATE = DateTime(1875, 5, 20, 0, 0, 0, 0), & !*** GREGORIAN_REFERENCE_DATE = DateTime(1582, 10, 15, 0, 0, 0, 0) !*** contains function getString(dt, FMT) result(string) character(:), allocatable :: string class(DateTime), intent(IN) :: dt integer, optional, intent(IN) :: FMT continue string = dt%getFormattedString(0, FMT) end function function getDateString(dt, FMT) result(string) character(:), allocatable :: string class(DateTime), intent(IN) :: dt integer, optional, intent(IN) :: FMT continue string = dt%getFormattedString(1, FMT) end function function getTimeString(dt, FMT) result(string) character(:), allocatable :: string class(DateTime), intent(IN) :: dt integer, optional, intent(IN) :: FMT continue string = dt%getFormattedString(2, FMT) end function elemental function getFormattedString(this, FILTER, FMT) & result(string) character(:), allocatable :: string class(DateTime), intent(IN) :: this integer, optional, intent(IN) :: FILTER, FMT continue string = '' end function end module datetime_mod gfortran does not recognize getFormattedString as a type-bound procedure. There are also errors related to the use of a deferred-length character as a function result (reported as Bug 49110), and an unnecessary warning about the duplicate save attribute. The exact output is: ...:~$ gfortran -c test_gfortran_missing_tbp.f90 test_gfortran_missing_tbp.f90:27.38: string = dt%getFormattedString(0, FMT) 1 Error: 'getformattedstring' at (1) is not a member of the 'datetime' structure test_gfortran_missing_tbp.f90:35.38: string = dt%getFormattedString(1, FMT) 1 Error: 'getformattedstring' at (1) is not a member of the 'datetime' structure test_gfortran_missing_tbp.f90:43.38: string = dt%getFormattedString(2, FMT) 1 Error: 'getformattedstring' at (1) is not a member of the 'datetime' structure test_gfortran_missing_tbp.f90:46.4: elemental function getFormattedString(dt, FILTER, FMT) & 1 Error: CHARACTER(*) function 'getformattedstring' at (1) cannot be pure test_gfortran_missing_tbp.f90:46.4: elemental function getFormattedString(dt, FILTER, FMT) & 1 Error: CHARACTER(*) function 'getformattedstring' at (1) cannot be pure test_gfortran_missing_tbp.f90:46.4: elemental function getFormattedString(dt, FILTER, FMT) & 1 Error: CHARACTER(*) function 'getformattedstring' at (1) cannot be pure test_gfortran_missing_tbp.f90:18.62: ISO_REFERENCE_DATE = DateTime(1875, 5, 20, 0, 0, 0, 0), & !*** 1 Warning: Duplicate SAVE attribute specified at (1) test_gfortran_missing_tbp.f90:18.62: ISO_REFERENCE_DATE = DateTime(1875, 5, 20, 0, 0, 0, 0), & !*** 1 Warning: Duplicate SAVE attribute specified at (1) If I remove the three lines marked with "!***" and also remove the ELEMENTAL attribute from the getFormattedString function, and compile again, then I get an internal compiler error: ...:~$ gfortran -c test_gfortran_ice.f90 test_gfortran_ice.f90:20.41: class(DateTime), intent(IN) :: dt 1 Warning: Duplicate SAVE attribute specified at (1) test_gfortran_ice.f90:20.41: class(DateTime), intent(IN) :: dt 1 Warning: Duplicate SAVE attribute specified at (1) test_gfortran_ice.f90: In function ‘gettimestring’: test_gfortran_ice.f90:41:0: internal compiler error: in fold_convert_loc, at fold-const.c:1906 Please submit a full bug report, with preprocessed source if appropriate. See for instructions The version information is: ...:~$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=
[Bug fortran/49112] Missing type-bound procedure, "duplicate save" warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #1 from John 2011-05-22 16:15:24 UTC --- Created attachment 24329 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24329 Test case
[Bug fortran/49112] Missing type-bound procedure, "duplicate save" warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #2 from John 2011-05-22 16:16:25 UTC --- Created attachment 24330 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24330 Test case for ICE
[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111 --- Comment #1 from John 2011-05-22 16:14:48 UTC --- Created attachment 24328 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24328 Test case
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 --- Comment #1 from John 2011-05-22 16:13:49 UTC --- Created attachment 24327 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24327 Test case
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
--- Comment #4 from John 2011-05-22 16:46:32 UTC
---
(In reply to comment #2)
> This patch allows your code to compile, but I
> don't know if it works correctly. Do you have
> a complete self-contained small testcase?
>
> Index: resolve.c
> ===
> --- resolve.c (revision 173757)
> +++ resolve.c (working copy)
> @@ -10305,7 +10305,7 @@ resolve_fl_procedure (gfc_symbol *sym, i
> actual length; (ii) To declare a named constant; or (iii) External
> function - but length must be declared in calling scoping unit. */
>if (sym->attr.function
> - && sym->ts.type == BT_CHARACTER
> + && sym->ts.type == BT_CHARACTER && !sym->ts.deferred
>&& sym->ts.u.cl && sym->ts.u.cl->length == NULL)
> {
>if ((sym->as && sym->as->rank) || (sym->attr.pointer)
The module shown is self-contained (it only depends on iso_c_binding, which is
an intrinsic module). I've added the corresponding source file to this bug as
an attachment.
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
--- Comment #3 from John 2011-05-22 16:45:09 UTC
---
(In reply to comment #2)
> This patch allows your code to compile, but I
> don't know if it works correctly. Do you have
> a complete self-contained small testcase?
>
> Index: resolve.c
> ===
> --- resolve.c (revision 173757)
> +++ resolve.c (working copy)
> @@ -10305,7 +10305,7 @@ resolve_fl_procedure (gfc_symbol *sym, i
> actual length; (ii) To declare a named constant; or (iii) External
> function - but length must be declared in calling scoping unit. */
>if (sym->attr.function
> - && sym->ts.type == BT_CHARACTER
> + && sym->ts.type == BT_CHARACTER && !sym->ts.deferred
>&& sym->ts.u.cl && sym->ts.u.cl->length == NULL)
> {
>if ((sym->as && sym->as->rank) || (sym->attr.pointer)
The module shown is self-contained (it only depends on iso_c_binding, which is
an intrinsic module). I've added the corresponding source file to this bug as
an attachment.
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 --- Comment #5 from John 2011-05-22 16:57:02 UTC --- Created attachment 24331 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24331 Test case with main unit
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 --- Comment #7 from John 2011-05-22 17:24:07 UTC --- (In reply to comment #6) > On Sun, May 22, 2011 at 04:57:44PM +0000, jwmwalrus at gmail dot com wrote: > > > This patch allows your code to compile, but I > > > don't know if it works correctly. Do you have > > > a complete self-contained small testcase? > > > > > > > The module shown is self-contained (it only depends on iso_c_binding, which > > is > > an intrinsic module). I've added the corresponding source file to this bug > > as > > an attachment. > > > > That's no what I meant. Obviously, I already stated > the patch allowed me compile your code. > > Do you have a COMPLETE self-contained testcase? As in > > program foo >use mod1 >DO SOMETHING HERE TO USE c2fstring() > end program foo Sorry for the double post (I now know the effect of the refresh button on Bugzilla). As I said, the source code is attached (the label is "Test case with main unit", the name of the file is test_gfortran_pure_main.f90).
[Bug fortran/49112] Missing type-bound procedure, "duplicate save" warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #4 from John 2011-05-22 17:58:39 UTC --- (In reply to comment #3) > (In reply to comment #0) > > ...:~$ gfortran -c test_gfortran_ice.f90 > > test_gfortran_ice.f90:20.41: > > > > class(DateTime), intent(IN) :: dt > > 1 > > Warning: Duplicate SAVE attribute specified at (1) > > test_gfortran_ice.f90:20.41: > > > > class(DateTime), intent(IN) :: dt > > 1 > > Warning: Duplicate SAVE attribute specified at (1) > > > Here is a reduced test case for the duplicate SAVE attribute: > > > module datetime_mod > > implicit none > save > > type :: DateTime > end type > > contains > > character function getString (dt) > class(DateTime) :: dt > end function > > end module > > > At first glance I would save this is invalid, and should be rejected with an > error. In particular, is it allowed to give a lonely SAVE statement? If yes, > what effect should this have? Usually SAVE is specified as an attribute for a > specific variable, right? SAVE can be either a statement or an attribute. When it's statement, it affects all the variables within the containing unit (e.g., in the case of a module, it affects all the variables declared before the "contains"). When it's the attribute for a particular variable declaration, it affects the variable only. Since in Fortran initialization implies SAVE, and the ISO_REFERENCE_DATE is being (sort of) initialized, the compiler is assuming a duplicate SAVE. The standard also allows the confirmation, as an attribute, of the SAVE at the module level, so, for a "triple save" example: module t1_mod save type :: t1 integer :: dummy = 0 end type type(t1), save :: a = t1(2), b = t1(3) end type Which also triggers a duplicate save warning.
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
--- Comment #10 from John 2011-05-22 19:36:33 UTC
---
(In reply to comment #9)
> Note the routine need not be pure to invoke the segfault. Here's
> an even shorter test case.
>
> program foo
>implicit none
>character s(5)
>s = ['a', 'b', 'c', 'd', 'e']
>print *, bar(s)
>contains
> function bar(s) result(a)
> ! character, intent(in) :: s(5) ! Compiles and runs
> character, intent(in) :: s(:)! Compiles and segfaults
> character(len=:), allocatable :: a
> a = repeat('a', size(s))
> end function bar
> end program foo
My bug report is actually about the fact that the "pure" attribute triggers an
(incorrect) error, and that error is associated to the deferred-length
character result. The code compiles just fine by removing the "pure" attribute
from the original code... Or by changing "character(:), allocatable :: string"
to something like "character(2047) :: string".
So I guess the subject line is fine.
The reason why I used interoperability with C, is because the module is just a
reduced version of the actual, practical case that triggered the error ---sorry
if it's "garbage" to you.
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, "duplicate save" warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #8 from John 2011-05-28 16:28:15 UTC --- (In reply to comment #5) > (In reply to comment #4) > > SAVE can be either a statement or an attribute. When it's statement, it > > affects all the variables within the containing unit > > Yes, of course. I completely forgot about this possibility. > > Btw, the code in comment #3 works with gfortran 4.5, so it is in fact a > regression. > > > > The standard also allows the confirmation, as an attribute, of the SAVE at > > the > > module level, so, for a "triple save" example: > > > > module t1_mod > > save > > > > type :: t1 > > integer :: dummy = 0 > > end type > > > > type(t1), save :: a = t1(2), b = t1(3) > > end type Sorry, it should have been "end module" > > > > > > Which also triggers a duplicate save warning. > > This is at best a "double save", and I think the (F08) standard forbids it: > > C580 (R553) If a SAVE statement with an omitted saved entity list appears in a > scoping unit, no other appearance of the SAVE attr-spec or SAVE statement is > permitted in that scoping unit. > t > So I think in this case gfortran correctly complains about a "Duplicate SAVE > attribute". Ups... I completely forgot about that constraint (I must have been thinking about section 5.3.16, which mentions an implicit SAVE statement for modules, and that one can be explicitly confirmed). So yes, it's at best an extension to the standard. Intel's and Sun's compilers complain about it: ...:~$ ifort -stand -c t1.f90 t1.f90(8): warning #7652: The F2003 standard says that the SAVE attribute is invalid since there is an occurrence of a SAVE statement with an omitted save-entity-list in the same scoping unit. [SAVE] type(t1), save :: a = t1(2), b = t1(3) ...:~$ sunf95 -ansi -c t1.f90 type(t1), save :: a = t1(2), b = t1(3) ^ "t1.f90", Line = 8, Column = 15: ANSI: The Fortran standard requires a SAVE statement with no saved-entity-list to be the only SAVE in the scoping unit. One thing about the original code, is that the "duplicate save" warning is being issued for an entity with the PARAMETER attribute ---so the SAVE at the scoping unit shouldn't even affect it, since the entity is not really a variable.
[Bug fortran/104630] module subroutine not accessible from submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104630 --- Comment #2 from John --- This issue is still in v12.2.0.
[Bug fortran/107742] New: class mismatch in passed procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107742 Bug ID: 107742 Summary: class mismatch in passed procedure Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Target Milestone: --- Hi. The code below throws the following error: 51 | if (this%match(my_proc, 5)) continue | 1 Error: Interface mismatch in dummy procedure ‘proc’ at (1): Type mismatch in argument 'this' (CLASS(a)/CLASS(b)) --8<-- module mod1 type, abstract :: a contains procedure(i_match), deferred :: match end type abstract interface subroutine i_proc(this, i) import class(a), intent(inout) :: this integer, intent(in) :: i end subroutine function i_match(this, proc, i) result(cond) import logical :: cond class(a), intent(inout) :: this procedure(i_proc) :: proc integer, intent(in) :: i end function end interface type, extends(a) :: b contains procedure :: match => match_b procedure :: exec end type interface module subroutine exec(this) class(b), intent(inout) :: this end subroutine end interface contains function match_b(this, proc, i) result(cond) logical :: cond class(b), intent(inout) :: this procedure(i_proc) :: proc integer, intent(in) :: i call proc(this, i) cond = .true. end function subroutine my_proc(this, i) class(b), intent(inout) :: this integer, intent(in) :: i end subroutine end module submodule (mod1) smod1 contains module procedure exec if (this%match(my_proc, 5)) continue end procedure end submodule -->8-- Since type b extends type a, doesn't my_proc satisfy the i_proc interface?
[Bug fortran/107872] New: ICE on recursive DT with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 Bug ID: 107872 Summary: ICE on recursive DT with DTIO Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Target Milestone: --- Hi. The code below throws the following ICE: $ gfortran -c -fbacktrace test2.f90 gfortran: internal compiler error: Segmentation fault signal terminated program f951 Please submit a full bug report, with preprocessed source (by using -freport-bug). See for instructions. --8<-- module mod1 type t integer :: data type(t), allocatable :: next contains procedure, private :: write_t generic :: write(formatted) => write_t end type contains recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg) class(t), intent(in) :: this integer, intent(in) :: unit character(*), intent(in) :: iotype integer, intent(in) :: v_list(:) integer, intent(out) :: iostat character(*), intent(inout) :: iomsg if (ALLOCATED(this%next)) & write (unit, '(dt)') this%next end subroutine end module -->8-- $ gfortran --version GNU Fortran (Debian 12.2.0-9) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
