[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 --- Comment #6 from Arjen Markus --- Thanks for the explanation and the adjusted example. This is clear enough.
[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 --- Comment #4 from Arjen Markus --- It was precisely this sort of issues that led me to write this small sample program. And I realised this morning, that indeed the host variables need to be avoided. But does: - loop_body accesses the host-associated, non-threadprivate variables q, x, and id, and you get data races mean that it is utterly unsafe to access even the shared variables (x and id in this case)? That would defy the intentions of using a(n internal) routine altogether. I need to have access to the entire array and the pattern of iterations avoids data collisions. (The I/O was an attempt to understand what was going on, as well as getting slightly more work done per iteration)
[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 --- Comment #2 from Arjen Markus --- Clear, so the workaround I found actually constitutes the proper method of doing this?
[Bug fortran/82895] New: An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 Bug ID: 82895 Summary: An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arjen.markus at deltares dot nl Target Milestone: --- Created attachment 42559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42559=edit Sample program exhibiting the bug Background: I want to use OpenMP to parallellise a large DO-loop in one of my programs. Due to the updates to the arrays that are involved and the patterns of in which the updates occur in a sequential run, I can do that via a nested loop, thus avoiding collisions - i.e. both array elements A(i) and A(j) are updated in a single iteration, but by structuring the DO-loop in an outer one that is parallellised and an inner one that is not, I avoid such collisions. To avoid duplication of the code (I need two sets of DO-loops), I want to use an internal routine. The attached program fails as the loop variable j (thread-private) does not get the right value inside the internal routine loop_body. If I change the signature to pass j explicitly as an actual argument, all seems to work well. There is no such problem for the shared arrays. My preliminary conclusion is that such private variables are not passed correctly to internal routines. Sample output (intended: the number of iterations per thread): $ ./chkloop_internal 1 10 2 0 3 0 4 0 5 0 6 0 7 0 8 0 instead of a more evenly spread of the iterations over the threads - actually because the index j has the value 0, the counting does not work at all.
[Bug fortran/82056] New: Automatic array can be sized via allocatable array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82056 Bug ID: 82056 Summary: Automatic array can be sized via allocatable array Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arjen.markus at deltares dot nl Target Milestone: --- The following program is accepted without complaints from the compiler: module chkdim implicit none contains subroutine calculate real, dimension(:), allocatable :: x real, dimension(size(x)):: y write(*,*) 'Sizes:', size(x), size(y) end subroutine calculate end module chkdim program chkit use chkdim call calculate end program chkit The problem however is that by relating the size of the automatic array (y) to that of a (local) allocatable array, the size of y is essentially undetermined. Ideally, the compiler should issue an error or a warning about it.
[Bug fortran/56667] New: Syntax error causes misleading message: Expected PARAMETER symbol in complex constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56667 Bug #: 56667 Summary: Syntax error causes misleading message: Expected PARAMETER symbol in complex constant Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl The following program causes the error message Expected PARAMETER symbol in complex constant, whereas the true error is the omission of a closing parenthesis. ! error_message.f90 -- ! Misleading error message ! program error_message implicit none integer :: ir write(*,*) ( ir, ir = 1,10 end program error_message
[Bug fortran/56520] New: Syntax error causes misleading message: Invalid character in name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520 Bug #: 56520 Summary: Syntax error causes misleading message: Invalid character in name Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl An extra parenthesis at the end of a statement leads to the error message: Invalid character in name at (1) The message has nothing to do with the actual error. Here is a small program to reproduce it: ! misleading.f90 -- ! Syntax error is reported with a misleading message ! program misleading implicit none real :: a, b, c a = 1.0 b = 1.0 c = exp(-a*b) ) end program misleading
[Bug fortran/56284] New: ICE with contained routine which inappropriately compares a string and a number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56284 Bug #: 56284 Summary: ICE with contained routine which inappropriately compares a string and a number Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl Created attachment 29414 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29414 Code that causes the compiler to fail The attached code causes an ICE in gfortran 4.7.2 (and 4.7.1) on Windows 7. The fact that the routine is contained in a derived type is essential for the occurrence of the ICE. On my system there is just the message that an ICE occurred, if I comment out the lines contains and procedure :: getRecord, then the compiler rightly complains about the mistake in the getRecord routine.
[Bug fortran/56284] ICE with contained routine which inappropriately compares a string and a number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56284 --- Comment #1 from Arjen Markus arjen.markus at deltares dot nl 2013-02-11 09:01:29 UTC --- Correcting the mistakes still causes an ICE
[Bug fortran/53537] New: Abstract interface with import interferes with only-clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537 Bug #: 53537 Summary: Abstract interface with import interferes with only-clause Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl The program below gives errors on the use of the parameter wp. If the interface is not present, the program gets compiled. It is probably possible to reduce it even further, but the error disappears when the only: wp = dp clause is commented out. module select_precision implicit none integer, parameter :: sp = kind( 1.0 ) integer, parameter :: dp = kind( 1.0d0 ) integer, parameter :: wp = sp end module select_precision module ode_types use select_precision, only: wp = dp implicit none private public :: wp type, abstract, public :: ode_system_t real(wp), dimension(:), allocatable :: x, x1, x2, x3, x4 real(wp):: time, deltt integer :: size = 0 end type ode_system_t interface function ode_derivative( this, x, time ) result(deriv) import :: ode_system_t, wp class(ode_system_t):: this real(wp), dimension(:) :: x real(wp) :: time real(wp), dimension(size(x)) :: deriv end function ode_derivative end interface end module ode_types
[Bug fortran/51550] New: ICE in gfc_get_derived_type, at fortran/trans-types.c:2401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51550 Bug #: 51550 Summary: ICE in gfc_get_derived_type, at fortran/trans-types.c:2401 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl Created attachment 26078 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26078 Program causing the ICE The attached program causes an ICE in gfc_get_derived_type, at fortran/trans-types.c:2401, both in version 4.6.2 and 4.7.0 20111212 (a very recent nightly build). The reported location is the same. It may be related to other reported bugs vis-a-vis gfc_get_derived_type, but as far as I can tell, they concern a different location in the source file. The report is: Driving: gfortran -v -o json json_problem.f90 -l gfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=d:/gfortran47/bin/../libexec/gcc/i586-pc-mingw32/4.7.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto Thread model: win32 gcc version 4.7.0 20111212 (experimental) [trunk revision 182257] (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'json.exe' '-shared-libgcc' '-mtune=pentium' '-march=pentium' d:/gfortran47/bin/../libexec/gcc/i586-pc-mingw32/4.7.0/f951.exe json_problem.f90 -quiet -dumpbase json_problem.f90 -mtune=pentium -march=pentium -auxbase json_problem -version -fintrinsic-modules-path d:/gfortran47/bin/../lib/gcc/i586-pc-mingw32/4.7.0/finclude -o e:\Temp\cc481Bzh.s GNU Fortran (GCC) version 4.7.0 20111212 (experimental) [trunk revision 182257] (i586-pc-mingw32) compiled by GNU C version 4.7.0 20111212 (experimental) [trunk revision 182257], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.7.0 20111212 (experimental) [trunk revision 182257] (i586-pc-mingw32) compiled by GNU C version 4.7.0 20111212 (experimental) [trunk revision 182257], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 json_problem.f90:50:0: internal compiler error: in gfc_get_derived_type, at fortran/trans-types.c:2401 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Regards, Arjen
[Bug fortran/51052] New: Internal compiler error in gfc_conv_component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51052 Bug #: 51052 Summary: Internal compiler error in gfc_conv_component Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl Created attachment 25767 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25767 Compressed tar file with two source files. The attached program source causes the compiler to stop with the message: particles.f90: In function 'position_oil_particle': particles.f90:142:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:523 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The version information of the compiler is: Built by Equation Solution http://www.Equation.com. Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=d:/gcc4.6.2/bin/../libexec/gcc/i686-pc-mingw32/4.6.2/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ../gcc-4.6.2-mingw/configure --host=i686-pc-mingw32 --build=x86_64-unknown-linux-gnu --target=i686-pc-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.6.2 --with-gcc --with-gnu-as --with-gnu-ld --with-host-libstdcxx='-lstdc++ -lsupc++ -lm' --with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/ppl --with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog --with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.6.2 --disable-shared --disable-nls --disable-tls --disable-win32-registry --enable-libquadmath-support --enable-libquadmath --enable-languages=c,c++,fortran --enable-libgomp --enable-threads=win32 --enable-lto --enable-static --enable-shared=lto-plugin --enable-plugins --enable-ld=yes --enable-cloog-backend=ppl Thread model: win32 gcc version 4.6.2 (GCC) The command I used to compile and link the program was: gfortran -o particles points2d3d.f90 particles.f90
[Bug fortran/47728] New: Assigning an object of one type to a class variable leads to an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47728 Summary: Assigning an object of one type to a class variable leads to an ICE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl The following program produces an internal compiler error: program test_objects implicit none type, abstract :: shape end type type, extends(shape) :: rectangle real :: width, height end type class(shape), dimension(2) :: object object(1) = rectangle( 1.0, 2.0 ) end program test_objects There is no indication as to what is wrong with the program (as Janus, who reduced my original program to this minimal one, remarks: there are at least two)
[Bug fortran/47730] New: ICE as a consequence of invalid source code attempting to register a type-bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47730 Summary: ICE as a consequence of invalid source code attempting to register a type-bound procedure Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl The code below produces an ICE after reporting that assign_square must be a module procedure or an external procedure. It seems related to bug #46849 module geometrical_objects implicit none type, abstract :: shape end type shape type, extends(shape) :: rectangle real :: width, height end type rectangle type, extends(rectangle) :: square contains procedure :: assign_square end type square contains subroutine assign_rectangle( this, that ) class(shape), intent(inout) :: this class(rectangle), intent(in):: that select type( that ) class is (rectangle) end select end subroutine assign_rectangle subroutine assign_square( this, that ) class(shape), intent(inout) :: this class(square), intent(in):: that end subroutine assign_square end module geometrical_objects
