[Bug fortran/86551] New: [ICE] bare class and select type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551 Bug ID: 86551 Summary: [ICE] bare class and select type Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- The following program produces an internal compiler error for me. module a type, abstract :: t1 end type type, extends(t1) :: t2 end type contains subroutine b implicit none class(t1) :: c2 select type (d => c2) end select type end subroutine b end module a Removing the select type statement gives the expected error: a.f90:9:19: class(t1) :: c2 1 Error: CLASS variable ‘c2’ at (1) must be dummy, allocatable or pointer Adding allocatable or pointer attributes fixes the ICE.
[Bug fortran/85675] New: parameters from other modules in openmp default(none) not specified in enclosing 'parallel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85675 Bug ID: 85675 Summary: parameters from other modules in openmp default(none) not specified in enclosing 'parallel' Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- I have been experiencing an issue (for a few versions already) related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 but in the case where the parameter is imported from a module in a different source file. c.f90: module c integer, parameter :: n = 100 integer, parameter :: ns(n) = 0 end module c test.f90: program test use c implicit none integer :: i !$omp parallel do default(none) private(i) do i=1,n write(*,*) ns(i) end do !$omp end parallel do end program test gfortran -fopenmp -c c.f90 gfortran -fopenmp -c test.f90 test.f90:8:0: write(*,*) ns(i) Error: ‘ns’ not specified in enclosing ‘parallel’ test.f90:6:0: !$omp parallel do default(none) private(i) Error: enclosing ‘parallel’
[Bug fortran/83458] F2008: inquire fails on units opened with newunit=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83458 --- Comment #3 from Daan van Vugt --- Ahh, okay, thanks! On Fri, Dec 22, 2017 at 5:58 AM, jvdelisle at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83458 > > Jerry DeLisle changed: > >What|Removed |Added > > > Status|ASSIGNED|RESOLVED > Resolution|--- |INVALID > > --- Comment #2 from Jerry DeLisle --- > You have your inquire arguments wrong > > Try: > > inquire(unit=un, opened=openedq, name=name_of_file) > > or > > inquire(number=un, opened=openedq, file="/dev/urandom") > > Marking as invalid > > -- > You are receiving this mail because: > You reported the bug. >
[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83436 --- Comment #16 from Daan van Vugt --- Thanks guys :) What version will this be included in? On Thu, Dec 21, 2017 at 11:36 AM, tkoenig at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83436 > > Thomas Koenig changed: > >What|Removed |Added > > > Status|WAITING |RESOLVED > Resolution|--- |FIXED > > --- Comment #15 from Thomas Koenig --- > Test case committed to trunk and gcc-7, closing. > > -- > You are receiving this mail because: > You reported the bug. >
[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83436 --- Comment #10 from Daan van Vugt --- (In reply to Steve Kargl from comment #8) > Thanks. Can you add the -v option to the above command line > and report the output (up to the ld line)? Do you have > more than one version of gfortran installed? No other versions of fortran are installed. Driving: gfortran -v -g read_urandom.f90 -o read_urandom -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp Thread model: posix gcc version 7.2.1 20171128 (GCC) COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'read_urandom' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/f951 read_urandom.f90 -quiet -dumpbase read_urandom.f90 -mtune=generic -march=x86-64 -auxbase read_urandom -g -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/finclude -o /tmp/ccSKp3n4.s GNU Fortran (GCC) version 7.2.1 20171128 (x86_64-pc-linux-gnu) compiled by GNU C version 7.2.1 20171128, GMP version 6.1.2, MPFR version 3.1.6-p1, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 7.2.1 20171128 (x86_64-pc-linux-gnu) compiled by GNU C version 7.2.1 20171128, GMP version 6.1.2, MPFR version 3.1.6-p1, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'read_urandom' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o /tmp/ccNuPWq3.o /tmp/ccSKp3n4.s GNU assembler version 2.29.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.29.1 Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../lib/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'read_urandom' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'read_urandom' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/collect2 -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper -plugin-opt=-fresolution=/tmp/ccwPVEu2.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -o read_urandom /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../.. /tmp/ccNuPWq3.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../lib/crtn.o COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'read_urandom' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83436 --- Comment #7 from Daan van Vugt --- (In reply to kargl from comment #6) > That is not gfortran. What happens if (1) you remove all of the > options and (2) you actually invoke gfortran? gfortran -g read_urandom.f90 -o read_urandom ./read_urandom At line 16 of file read_urandom.f90 Fortran runtime error: Internal file cannot be accessed by UNFORMATTED data transfer [backtrace] gfortran --version GNU Fortran (GCC) 7.2.1 20171128
[Bug fortran/83458] New: F2008: inquire fails on units opened with newunit=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83458 Bug ID: 83458 Summary: F2008: inquire fails on units opened with newunit= Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- Whens trying to find information an a unit number this fails if the unit number is opened with newunit= I expect the program below to return a unit number < 0, ierr=0, T and the filename. program inquire_newunit integer :: un, ierr character(len=80) :: name_of_file logical :: openedq open(newunit=un, file="/dev/urandom", access="stream", & form="unformatted", action="read", status="old", iostat=ierr) inquire(number=un, opened=openedq, file=name_of_file) write(*,*) un, ierr, openedq write(*,*) name_of_file if (ierr == 0) then close(un) end if end program inquire_newunit
[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83436 --- Comment #5 from Daan van Vugt --- Okay, turned out I missed the critical lines in my bug report... Could you try again with this example? module mod_random_seed implicit none contains !> Read an int from /dev/urandom subroutine read_urandom_int(seed, ierr) implicit none integer, intent(out) :: seed integer, intent(out) :: ierr integer :: un character(len=80) :: restart_file write(restart_file,'(A,A)') 'jorek', '_restart.h5' open(newunit=un, file="/dev/urandom", access="stream", & form="unformatted", action="read", status="old", iostat=ierr) if (ierr == 0) then read(un) seed close(un) end if end subroutine read_urandom_int end module mod_random_seed program test_random_seed use mod_random_seed integer :: seed, ierr call read_urandom_int(seed, ierr) write(*,*) seed, ierr end program test_random_seed I have compiled it as: mpif90 -march=native -cpp -fopenmp -Wall -Wextra -Wno-unused-variable -g -Og -ggdb -Wunused-variable -Wintrinsics-std -Wcharacter-truncation -Wsurprising -Wno-tabs -ffree-line-length-none -fcheck=all -ffpe-trap=invalid,zero,overflow -ftrapv -finit-real=snan -finit-integer=12345678 -Wimplicit-interface -Wimplicit-procedure -Wconversion -fimplicit-none read_urandom.f90 -o read_urandom This produces for me: At line 16 of file read_urandom.f90 Fortran runtime error: Internal file cannot be accessed by UNFORMATTED data transfer Error termination. Backtrace: #0 0x14fc70240043 in data_transfer_init at /build/gcc/src/gcc/libgfortran/io/transfer.c:2822 #1 0x55c83ae10e31 in __mod_random_seed_MOD_read_urandom_int at /media/data/Projects/gfortran/bugs/internal_file_urandom/read_urandom.f90:16 #2 0x55c83ae10ebd in test_random_seed at /media/data/Projects/gfortran/bugs/internal_file_urandom/read_urandom.f90:25 #3 0x55c83ae10f63 in main at /media/data/Projects/gfortran/bugs/internal_file_urandom/read_urandom.f90:23
[Bug fortran/83436] New: Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83436 Bug ID: 83436 Summary: Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- With the update to 7.2.1 the following code fragment starts failing: Fortran runtime error: Internal file cannot be accessed by UNFORMATTED data transfer !> Read an int from /dev/urandom subroutine read_urandom_int(seed, ierr) implicit none integer, intent(out) :: seed integer, intent(out) :: ierr integer :: un open(newunit=un, file="/dev/urandom", access="stream", & form="unformatted", action="read", status="old", iostat=ierr) if (ierr == 0) then read(un) seed close(un) end if end subroutine read_urandom_int I think this might be a regression. The same code works just fine in intel compiler and older gfortran versions.
[Bug fortran/82064] [OOP] multiple incompatible definitions of extended derived type via module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064 --- Comment #1 from Daan van Vugt --- the !use mod_boris should be !use mod_f to work around the problem in the attachment and code below
[Bug fortran/82064] New: [OOP] multiple incompatible definitions of extended derived type via module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064 Bug ID: 82064 Summary: [OOP] multiple incompatible definitions of extended derived type via module use Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- Created attachment 42097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42097=edit Makefile, base type, extra module and test program When using an extended derived type from a module through two, different, other modules they become incompatible. The interesting part is that I use `private` everywhere so the type itself is not actually shared. This results in interesting phenomena such as select type not working as expected, and errors of class(t1) not matching class(t1). In the attached zip file are the files needed to reproduce. Run `make` to create `test_sep` from test_sep.f90 which prints ERR twice on my machine. Putting all the modules and the program together in one file yields a program that prints OK twice. (test.f90) I have written some changes that cause the problem to disappear as comments. module mod_types type, abstract :: t end type t type, extends(t) :: t2 end type t2 end module mod_types module mod_f use mod_types implicit none private contains ! Remove this function to fix subroutine f(particle) ! if the classname here matches the type name in test_sep it breaks class(t2), intent(inout) :: particle ! using type instead of class here also works end subroutine f end module mod_f module mod_test use mod_types !use mod_boris ! uncomment for a fix implicit none private public :: init contains subroutine init(p) class(t), intent(inout) :: p select type (p) type is (t2) write(*,*) "OK" class default write(*,*) "ERR" end select end subroutine init end module mod_test program test_sep use mod_types use mod_f ! remove this to fix use mod_test class(t), allocatable :: p type(t2) :: p2 allocate(t2::p) call init(p) call init(p2) end program test_sep
[Bug fortran/78009] New: [OOP] polymorphic component of derived type array slice handling error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78009 Bug ID: 78009 Summary: [OOP] polymorphic component of derived type array slice handling error Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- When setting a component of a polymorphic type in an array memory offsets of the base type are used. This only occurs if it is nested in another allocatable array. See the attached program for an example. Expected output is 1 0 1 0 ... etc instead a different memory region is set to 1. program test type :: t integer :: a end type t type, extends(t) :: tt integer :: b end type tt type :: group class(t), allocatable, dimension(:) :: unit end type group type(group), allocatable, dimension(:) :: groups allocate(groups(1)) allocate(tt::groups(1)%unit(10)) groups(1)%unit(:)%a = 1 select type (units => groups(1)%unit) type is (tt) do i=1,10 write(*,*) units(i)%a, units(i)%b end do end select end program test
[Bug fortran/77412] constructor of an extended type with an allocatable component in the base type crashes gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77412 --- Comment #1 from Daan van Vugt --- Some more info: changing 1.0 to 1d0 does not prevent the crash. Adding a type constructor and changing 1.0 to 1d0 does work.
[Bug fortran/77412] New: constructor of an extended type with an allocatable component in the base type crashes gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77412 Bug ID: 77412 Summary: constructor of an extended type with an allocatable component in the base type crashes gfortran Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- The below segment causes gfortran 6.1.1 to crash with: test.f90:11:0: a = test_ext(timestep = 1.0) internal compiler error: in fold_convert_loc, at fold-const.c:2250 program test_allocatable_component type, abstract :: test_base real*8, allocatable :: timestep end type type, extends(test_base) :: test_ext end type type(test_ext) :: a a = test_ext(timestep = 1.0) end program test_allocatable_component For an integer, dimension(:) variable the exact same situation does work.
[Bug fortran/72832] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #5 from Daan van Vugt --- Thanks for the quick responses. Just out of interest: what is the recommended way to allocate a class(t) variable of the same type as a but different size? Do I need to select type and list all of the types? that would be inconvenient.
[Bug fortran/72832] New: [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 Bug ID: 72832 Summary: [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- If I try to allocate a polymorphic variable with a specific dimension I do not get the expected result. See this example: program allocate_source type :: t end type t type, extends(t) :: tt end type tt class(t), allocatable, dimension(:) :: a, b allocate(tt::a(1:2)) write(*,*) size(a,1) allocate(b(1:4), source=a) write(*,*) size(b,1) end program allocate_source Which produces as output 2 2 While I expect the second line to be 4.
