[Bug libfortran/85975] New: Incorrect size for spread array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85975 Bug ID: 85975 Summary: Incorrect size for spread array Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: stephan.kramer at imperial dot ac.uk Target Milestone: --- With the following program program foo implicit none call bar(2, 3, 5, 7) contains subroutine bar(k, l, m, n) integer, intent(in) :: k, l, m, n real, dimension(k) :: a real, dimension(k,l):: b real, dimension(k,l,m):: c real, dimension(k,l,m,n):: d print *, size(spread(A, 1, 1)) print *, size(spread(b, 1, 1)) print *, size(spread(c, 1, 1)) print *, size(spread(d, 1, 1)) end subroutine end program I get the following result: $ gfortran test2.f90 skramer@gyre:~/tst/gfortran8$ ./a.out 2 6 0 210 skramer@gyre:~/tst/gfortran8$ ./a.out 0 6 754395868 210 i.e. the results for the A and c arrrays are incorrect (and vary between subsequent reruns). After some digging in the libfortran source I think this is due to a bug in the GFC_DTYPE_COPY_SETRANK macro introduced in https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00369.html, where line 421 of libgfortran/libgfortran.h changed from (a)->dtype = (((b)->dtype & ~GFC_DTYPE_RANK_MASK) | n ); \ to (a)->dtype.rank = ((b)->dtype.rank | n ); \ The thing is that the "| n" makes sense in the previous case where the relevant bits that store the previous rank have been zeroed out first. Now that rank is a separate field, I think it should just be: (a)->dtype.rank = n Note that in the example above the even ranked arrays (B and D) do get the correct result. This is because in those cases it happens to be that new_rank==(old_rank | new_rank) (3 == 2 | 3 and 5 == 4 | 5). In the case of arrays A and C however, we get 1 | 2 == 3 and 3 | 4 == 7, so that the rank of the resulting spread array is too big, and the size calculations uses spurious uninitialised array extents. I have found, what I think are, related issues, when passing the result of spread of a rank-3 array into a subroutine, where in the "internal pack" routine would sometimes try to allocate a temporary that is way too big and cause an out of memory error (similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85816). Unfortunately this one seems a little harder to reproduce in a small program.
[Bug fortran/85938] New: Spurious assert failure for matmul with reshaped array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85938 Bug ID: 85938 Summary: Spurious assert failure for matmul with reshaped array Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stephan.kramer at imperial dot ac.uk Target Milestone: --- The following program program foo real, dimension(9) :: A real, dimension(3) :: b integer :: n = 3 A = 1.0 b = 1.0 print *, matmul(reshape(A, (/ n, n /)), b) end program compiled with, or without optimisation, produces the following runtime assertion failure in libgfortran: $ gfortran test.f90 $ ./a.out a.out: ../../../src/libgfortran/generated/matmul_r4.c:651: matmul_r4_avx2: Assertion `GFC_DESCRIPTOR_RANK (a) == 2 || GFC_DESCRIPTOR_RANK (b) == 2' failed. Program received signal SIGABRT: Process abort signal. I also tried -fno-frontend-optimize to no avail. Backtrace in gdb: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x76dfc231 in __GI_abort () at abort.c:79 #2 0x76df39da in __assert_fail_base (fmt=0x76f46d48 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x77ba9ec8 "GFC_DESCRIPTOR_RANK (a) == 2 || GFC_DESCRIPTOR_RANK (b) == 2", file=file@entry=0x77baa300 "../../../src/libgfortran/generated/matmul_r4.c", line=line@entry=651, function=function@entry=0x77baa368 "matmul_r4_avx2") at assert.c:92 #3 0x76df3a52 in __GI___assert_fail (assertion=0x77ba9ec8 "GFC_DESCRIPTOR_RANK (a) == 2 || GFC_DESCRIPTOR_RANK (b) == 2", file=0x77baa300 "../../../src/libgfortran/generated/matmul_r4.c", line=651, function=0x77baa368 "matmul_r4_avx2") at assert.c:101 #4 0x77a5c9a3 in ?? () from /usr/lib/x86_64-linux-gnu/libgfortran.so.5 #5 0x4c32 in foo () at test.f90:8 #6 0x4cf0 in main (argc=1, argv=0x7fffe38c) at test.f90:10 #7 0x76de7a87 in __libc_start_main (main=0x4cba , argc=1, argv=0x7fffe088, init=, fini=, rtld_fini=, stack_end=0x7fffe078) at ../csu/libc-start.c:310 #8 0x482a in _start () This is based on source and debugging symbols for Debian gcc-8 8.1.0-3
[Bug fortran/85750] New: Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 Bug ID: 85750 Summary: Default initialization of derived type array missing Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stephan.kramer at imperial dot ac.uk Target Milestone: --- In The following program, the derived type array that is returned by make_list does not have its components initialized. module bar implicit none type ilist integer :: count = 0 integer, dimension(:), pointer :: ptr => null() end type ilist contains function make_list(i) integer, intent(in) :: i type(ilist), dimension(2) :: make_list make_list(i)%count = 1 end function make_list end module bar program foo use bar implicit none type(ilist), dimension(:), allocatable :: mylist allocate(mylist(1:2)) mylist = make_list(1) print *, mylist%count mylist = make_list(2) print *, mylist%count end program foo What I get: $ gfortran test.f90 $ ./a.out 1 0 1 1 What I expect: 1 0 0 1 i.e. make_list should return an array for which all entries have a zero %count component, except for the specified entry that's set to 1. The program does work correctly if I leave out the %ptr from the ilist derived type definition. Latest gfortran I've tried is 8.1, but I see the same failure on 7.3, 7.2 and 6.2. The results are correct with gfortran 5.4 $ gfortran -v test.f90 Driving: gfortran -v test.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.1.0-1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --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 --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.1.0 (Debian 8.1.0-1) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/8/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -march=x86-64 -auxbase test -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/8/finclude -o /tmp/cch78iQf.s GNU Fortran (Debian 8.1.0-1) version 8.1.0 (x86_64-linux-gnu) compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (Debian 8.1.0-1) version 8.1.0 (x86_64-linux-gnu) compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/bin/x86_64-linux-gnu-as -v --64 -o /tmp/ccwUDNGB.o /tmp/cch78iQf.s GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.30 Reading specs from /usr/lib/gcc/x86_64-linux-gnu/8/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper -plu
[Bug fortran/57798] New: Incorrect handling of sum over first dimension of a product of automatic arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Bug ID: 57798 Summary: Incorrect handling of sum over first dimension of a product of automatic arrays Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stephan.kramer at imperial dot ac.uk The test code below results in a segfault evaluating the sum() in the print statement. This is compiling with gfortran 4.8.1 (4.8.1-4ubuntu1 on Ubuntu Saucy) without any flags. If bounds checking is switched on (-fbounds-check) I get a bounds violation error with a random number reported for one of the bounds: Fortran runtime error: Dimension 1 of array 'func' has extent 2 instead of 4196256 Is this possibly related to the optimisation requested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841 ? program test implicit none call sub(2, 11) contains function func(m, n) integer, intent(in):: m,n real, dimension(m, n):: func func = 0.0 end function func subroutine sub(m, n) integer, intent(in):: m, n real, dimension(m,n):: y y = 0.0 print *, sum(y*func(m,n), dim=1) end subroutine sub end program test
[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function resul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389 --- Comment #2 from Stephan Kramer stephan.kramer at imperial dot ac.uk 2012-05-18 15:27:54 UTC --- (In reply to comment #1) Confirmed. Workaround is to use -fno-realloc-lhs Excellent. Thanks for the suggested workaround. That'll save us a lot of unnecessary refactoring.
[Bug fortran/53389] New: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389 Bug #: 53389 Summary: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: stephan.kra...@imperial.ac.uk The following test code leaks memory rapidly - reproduced on Ubuntu's gfortran 4.6.3, with gfortran 4.7.1 and with a nightly build of 4.8, trunk revision 187620 - default optimisation flags (none specified). As far as I've narrowed it down, it seems to occur when an array function result is assigned to an allocatable array, where one of the arguments supplied to this function is itself an array function result. In the example below, the outer function and the function supplied as an argument are the same, and the returned array is an automatic array, but that does not seems to be necessary to reproduce the problem. module foo implicit none contains function filler(array, val) real, dimension(:), intent(in):: array real, dimension(size(array)):: filler real, intent(in):: val filler=val end function filler end module program test use foo implicit none real, dimension(:), allocatable:: x, y integer, parameter:: N=1000*1000 integer:: i allocate( x(N), y(N) ) y=0.0 do i=1, N print *,i x=filler(filler(y, real(2*i)), real(i)) y=y+x end do end program test
[Bug fortran/49693] New: Spurious unused-variable warnings for COMMON block module variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693 Summary: Spurious unused-variable warnings for COMMON block module variables. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: stephan.kra...@imperial.ac.uk As of gfortran 4.6, module variables that are also part of a common block cause spurious unused variable warnings. The following example module foo implicit none integer:: a, b common a end module foo produces: $ gfortran -c -Wall test.f90 test.f90:3:0: warning: ‘a’ defined but not used [-Wunused-variable] Although common variables are deprecated they're still commonly used in libraries such as mpi and petsc to define some global paramaters. I therefore get quite a few warning messages in every module that uses these (and also everywhere module that subsequently uses such modules). Example here with openmpi: $ cat test.f90 module foo use mpi use petsc end module $ mpif90 -I/usr/lib/petscdir/3.1/linux-gnu-c-opt/include/ -Wall -c test.f90 test.f90:2:0: warning: ‘mpi_argv_null’ defined but not used test.f90:2:0: warning: ‘mpi_in_place’ defined but not used test.f90:2:0: warning: ‘mpi_status_ignore’ defined but not used test.f90:2:0: warning: ‘mpi_statuses_ignore’ defined but not used test.f90:3:0: warning: ‘petsc_comm_self’ defined but not used test.f90:3:0: warning: ‘petsc_null_integer’ defined but not used test.f90:3:0: warning: ‘petsc_null’ defined but not used test.f90:3:0: warning: ‘petsc_null_scalar’ defined but not used test.f90:3:0: warning: ‘petsc_null_double’ defined but not used test.f90:3:0: warning: ‘petsc_null_real’ defined but not used test.f90:3:0: warning: ‘petsc_null_truth’ defined but not used test.f90:2:0: warning: ‘mpi_argvs_null’ defined but not used test.f90:3:0: warning: ‘petsc_null_object’ defined but not used test.f90:3:0: warning: ‘petsc_comm_world’ defined but not used test.f90:2:0: warning: ‘mpi_argv_null’ defined but not used test.f90:2:0: warning: ‘mpi_argvs_null’ defined but not used test.f90:2:0: warning: ‘mpi_bottom’ defined but not used test.f90:2:0: warning: ‘mpi_errcodes_ignore’ defined but not used test.f90:2:0: warning: ‘mpi_in_place’ defined but not used test.f90:2:0: warning: ‘mpi_status_ignore’ defined but not used test.f90:2:0: warning: ‘mpi_statuses_ignore’ defined but not used test.f90:3:0: warning: ‘petsc_null_character’ defined but not used test.f90:2:0: warning: ‘mpi_bottom’ defined but not used test.f90:2:0: warning: ‘mpi_errcodes_ignore’ defined but not used
