[Bug fortran/85675] New: parameters from other modules in openmp default(none) not specified in enclosing 'parallel'

NCONFIRMED 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.or

[Bug fortran/83436] New: Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom

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

[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_u

[Bug fortran/83458] New: F2008: inquire fails on units opened with newunit=

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, i

[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_ura

[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 install

[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 >

[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: > >

[Bug fortran/86551] New: [ICE] bare class and select type

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

[Bug fortran/82064] New: [OOP] multiple incompatible definitions of extended derived type via module use

: 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&action=edit Makefile, ba

[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/78009] New: [OOP] polymorphic component of derived type array slice handling error

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

[Bug fortran/72832] New: [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

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

[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?

[Bug fortran/77412] New: constructor of an extended type with an allocatable component in the base type crashes gfortran

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

[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.