[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585 --- Comment #4 from Bill Long --- Any prediction for this one? (I realize you still have F2018 an F2023 to get through.)
[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219 --- Comment #12 from Bill Long --- Has this been fixed in a more recent version of gfortran?
[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585 Bill Long changed: What|Removed |Added CC||longb at cray dot com --- Comment #2 from Bill Long --- Bug 102369 was closed as a duplicate of THIS bug. Has this been fixed in a more recent version of gfortran?
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #10 from Bill Long --- The original issue seems fixed in 12.1. However, the wording of the ERROR message (objecting that something is not a DATA entity when it really is) could still be improved. Can we either convert this bug to that purpose or open a new one?
[Bug fortran/104252] New: OpenMP array reduction support issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104252 Bug ID: 104252 Summary: OpenMP array reduction support issue Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- Created attachment 52299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52299=edit Source for test case. For the attached test case source file: > gfortran -fopenmp array-reduction-test.F90 array-reduction-test.F90:26:37: 26 | !$omp parallel do reduction(+:a(i)) | 1 Error: Syntax error in OpenMP variable list at (1) array-reduction-test.F90:30:26: 30 | !$omp end parallel do | 1 Error: Unexpected !$OMP END PARALLEL DO statement at (1) > gfortran -fopenmp -DARRAY_SECTION array-reduction-test.F90 array-reduction-test.F90:18:37: 18 | !$omp parallel do reduction(+:a(i:1)) | 1 Error: Syntax error in OpenMP variable list at (1) array-reduction-test.F90:22:26: 22 | !$omp end parallel do | 1 Error: Unexpected !$OMP END PARALLEL DO statement at (1) > gfortran -fopenmp -DFULL_ARRAY array-reduction-test.F90 > gfortran --version GNU Fortran (GCC) 11.2.0 20210728 (Cray Inc.) Copyright (C) 2021 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. Gfortran seems to be OK with a whole array in an OpenMP reduction clause, but not with an array element or an array section. Other compilers (ifort, for example) accept all 3 forms.
[Bug libfortran/102370] Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370 --- Comment #2 from Bill Long --- I've sent a question back to the original submitter. On completion, the first argument to MOVE_ALLOC is unallocated, so it does look suspicious to be printing a component of an unallocated structure. I'll update when I get a revised test case.
[Bug fortran/102371] New: Error for type spec in FORALL statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371 Bug ID: 102371 Summary: Error for type spec in FORALL statement Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program main implicit none integer, parameter :: long = selected_int_kind(18) integer(long), parameter :: very_large = 128_long integer, allocatable, dimension(:,:) :: ary allocate(ary(very_large, 2)) forall(integer(long) :: i=1:very_large, j=1:2) ary(i, j) = i * j end forall print *, ary(5, 2) deallocate(ary) end program main > ifort test.f90 > ./a.out 10 > gfortran test.f90 test.f90:7:8: 7 | forall(integer(long) :: i=1:very_large, j=1:2) |1 Error: Syntax error in FORALL statement at (1) test.f90:9:3: 9 | end forall | 1 Error: Expecting END PROGRAM statement at (1) test.f90:8:5: 8 | ary(i, j) = i * j | 1 Error: Symbol 'i' at (1) has no IMPLICIT type test.f90:8:8: 8 | ary(i, j) = i * j |1 Error: Symbol 'j' at (1) has no IMPLICIT type I assume all the errors are a cascade from the first error, which is the issue in this bug. FORALL statements are supposed to allow a type spec.
[Bug demangler/102370] New: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370 Bug ID: 102370 Summary: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program main implicit none type mytype real :: val integer :: idx type(mytype), allocatable :: next end type mytype type (mytype), allocatable :: top, temp temp = mytype (5.0, 5, temp ) call move_alloc(top, temp%next) call move_alloc(temp, top) print *, temp%val end program main # Cray compiler > ftn test.f90 > ./a.out 5. > gfortran test.f90 > ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f88d658e49f in ??? #1 0x7f88d72fc5c0 in get_float_string at ../../../cray-gcc-11.2.0-202108140355.9bf1fd589a5c1/libgfortran/io/write_float.def:1110 #2 0x7f88d72fec65 in list_formatted_write_scalar at ../../../cray-gcc-11.2.0-202108140355.9bf1fd589a5c1/libgfortran/io/write.c:1903 #3 0x400c91 in ??? #4 0x401145 in ??? #5 0x7f88d6579349 in ??? #6 0x4007c9 in ??? at ../sysdeps/x86_64/start.S:120 #7 0x in ??? Segmentation fault (core dumped)
[Bug fortran/102369] VALUE attribute for arrays not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 --- Comment #1 from Bill Long --- I assume the cascade of error messages all originate with the first one. The combination of VALUE for an array is allowed in F08 and later versions.
[Bug fortran/102369] New: VALUE attribute for arrays not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 Bug ID: 102369 Summary: VALUE attribute for arrays not allowed Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 module mymod contains pure real function myfunc(x) integer, value, dimension(:), intent(in) :: x myfunc = x(1) end function myfunc end module mymod program main use mymod implicit none integer, parameter :: sz = 10 integer, dimension(sz) :: foo foo = 42 print *, myfunc(foo) end program main > ifort test.f90 > ./a.out 42.0 > gfortran test.f90 test.f90:4:14: 4 | integer, value, dimension(:), intent(in) :: x | 1 Error: VALUE attribute conflicts with DIMENSION attribute at (1) test.f90:3:27: 3 | pure real function myfunc(x) | 1 Error: Dummy procedure 'x' of PURE procedure at (1) must also be PURE test.f90:5:9: 5 | myfunc = x(1) | 1 Error: Reference to impure function 'x' at (1) within a PURE procedure test.f90:9:5: 9 | use mymod | 1 Fatal Error: Cannot open module file 'mymod.mod' for reading at (1): No such file or directory compilation terminated. > gfortran --version GNU Fortran (GCC) 11.2.0 20210728 (Cray Inc.) Copyright (C) 2021 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.
[Bug fortran/102368] New: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368 Bug ID: 102368 Summary: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program main use,intrinsic :: iso_c_binding implicit none character(kind=c_char, len=*), parameter :: blergh = 'abc' print *, c_sizeof(blergh) print *, c_sizeof(.true.) print *, c_sizeof(5) print *, c_sizeof(5.0) print *, c_sizeof(5.0d0) end program main > gfortran test.f90 test.f90:7:18: 7 | print *, c_sizeof(blergh) | 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be an interoperable data entity: Type shall have a character length of 1 > ifort test.f90 > ./a.out 3 4 4 4 8 gfortran appears to be using pre-F08 rules for C_SIZEOF.
[Bug fortran/101658] New: Bogus message for declaration of polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101658 Bug ID: 101658 Summary: Bogus message for declaration of polymorphic dummy argument Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- For this code: > cat test2.f90 module test_module use, intrinsic:: iso_fortran_env, only: int32 implicit none type, abstract :: hash_base_t contains procedure, nopass:: hash => dhash end type type, extends(hash_base_t), public:: hash_t(len) integer(kind=int32), len:: len=1 contains procedure:: get_len final:: finalise_hash end type contains pure elemental integer function dhash(key, start) character(len=*), intent(in):: key integer(kind=int32), intent(in), optional:: start dhash = 1 end function dhash pure integer function get_len(this) class(hash_t( * )), intent(in):: this get_len = this%len end function get_len subroutine finalise_hash(this) class(hash_t( * )), intent(inout):: this end subroutine finalise_hash end module test_module gfortran give this set of errors: > gfortran -c test2.f90 test2.f90:30:31: 30 | subroutine finalise_hash(this) | 1 Error: Argument of FINAL procedure at (1) must be of type 'hash_t' test2.f90:26:22: 26 | class(hash_t( * )), intent(in):: this | 1 Error: 'hash_base_t' at (1) is of the ABSTRACT type 'hash_base_t' test2.f90:26:22: 26 | class(hash_t( * )), intent(in):: this | 1 Error: 'hash_base_t' at (1) is of the ABSTRACT type 'hash_base_t' test2.f90:26:22: 26 | class(hash_t( * )), intent(in):: this | 1 Error: 'hash_base_t' at (1) is of the ABSTRACT type 'hash_base_t' > gfortran --version GNU Fortran (GCC) 10.3.0 20210408 (Cray Inc.) Copyright (C) 2020 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. The type of the argument is hash_t, and not hash_base_t. Maybe getting confused because hash_t is parameterized??
[Bug fortran/42954] [9/10/11/12 regression] TARGET_*_CPP_BUILTINS issues with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 --- Comment #35 from Bill Long --- A lot of users have moved to the 10.X series of compilers, and the adventurous ones to 11.X. Will the fixes also appear in those compilers?
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #7 from Bill Long --- Inquiry from the original site: "Does GCC provide a timeline for when they will conform to F2018?"
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #7 from Bill Long --- For our purposes, 10 will be fine.
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #9 from Bill Long --- The original test is not conforming due to the missing IMPORT statement. However, the error message , which I assume is for the second non-blank line in the listing, seems odd. The standard says "If RESULT does not appear, the name of the function result is function-name and all occurrences of the function name in execution-part statements in its scope are references to the function result. On completion of execution of the function, the value returned is that of its function result. " Technically, the reference to x in kind(x) is not in the execution part of the function, but rather in the specification part. However, the quote above from 15.6.2.2 para 4, does not really say anything about appearances in the specification part of the code. However, it appears that the line flagged with the message is the one containing the kind(x) reference in the the interface block. That is valid due to the missing IMPORT statement.
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #6 from Bill Long --- Is there a released version with the fix noted in this bug?
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #20 from Bill Long --- Original customer is asking about the status of this issue.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #10 from Bill Long --- Still fails with 10.2.0. Can you say which release version will include the fix?
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #5 from Bill Long --- Original customer is asking again...
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #5 from Bill Long --- Is this fixed in a release version of GCC?
[Bug libgomp/98699] Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699 --- Comment #3 from Bill Long --- Thanks, Tobias. GCC 11 should be fine. Great to see you back.
[Bug fortran/98699] New: Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699 Bug ID: 98699 Summary: Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1. Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- The user's desire is that, for an OpenMP code, if the maximum number of active levels (OMP_MAX_ACTIVE_LEVELS) has a value greater than 1 then the internal variable for nesting (OMP_NESTING) automatically be reset to .true. . The Cray and Intel compilers appear to do this (and issue a message about OMP_NESTING being deprecated) while gfortran does not. If NESTING is disabled, having the maximum number of active levels greater than 1 does not seem to make sense. Simple test code: > cat test.f90 program list_omp_internan_vars use omp_lib integer active logical nested nested = omp_get_nested() print *, "Internal value for omp_nested is ", nested active = omp_get_max_active_levels() print *, "Internal value for omp_max_active_levels is ", active end program list_omp_internan_vars For gfortran: > gfortran -fopenmp test.f90 > export OMP_MAX_ACTIVE_LEVELS=1 > srun -n1 -c4 ./a.out Internal value for omp_nested is F Internal value for omp_max_active_levels is 1 > export OMP_MAX_ACTIVE_LEVELS=4 > srun -n1 -c4 ./a.out Internal value for omp_nested is F Internal value for omp_max_active_levels is 4 > gfortran --version GNU Fortran (GCC) 10.2.0 20200723 (Cray Inc.) Copyright (C) 2020 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. Same example with CCE: > ftn -homp test.f90 > export OMP_MAX_ACTIVE_LEVELS=1 > srun -n1 -c4 ./a.out WARNING: omp_get_nested has been deprecated in OpenMP 5.0. Internal value for omp_nested is F Internal value for omp_max_active_levels is 1 > export OMP_MAX_ACTIVE_LEVELS=4 srun -n1 -c4 ./a.out WARNING: omp_get_nested has been deprecated in OpenMP 5.0. Internal value for omp_nested is T Internal value for omp_max_active_levels is 4 Same example with Intel ( same convention as the Cray compiler): > export OMP_MAX_ACTIVE_LEVELS=1 > ifort -qopenmp test.f90 > srun -n1 -c4 ./a.out OMP: Info #274: omp_get_nested routine deprecated, please use omp_get_max_active_levels instead. Internal value for omp_nested is F Internal value for omp_max_active_levels is 1 > export OMP_MAX_ACTIVE_LEVELS=4 > srun -n1 -c4 ./a.out OMP: Info #274: omp_get_nested routine deprecated, please use omp_get_max_active_levels instead. Internal value for omp_nested is T Internal value for omp_max_active_levels is 4
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #5 from Bill Long --- Original submitter asking for a fixed-in version number.
[Bug fortran/42478] [meta-bug] gfortran OpenMP bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478 Bug 42478 depends on bug 40876, which changed state. Bug 40876 Summary: OpenMP private variable referenced in a statement function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876 What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |---
[Bug fortran/40876] OpenMP private variable referenced in a statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876 Bill Long changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #11 from Bill Long --- With 10.2.0 there is still no error message for the invalid use of A in a private() clause of the OpenMP directive.
[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 --- Comment #12 from Bill Long --- Original submitter asking which GCC version(s) have / will have the fix.
[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 --- Comment #18 from Bill Long --- Original submitted asking about the GCC version that has / will have the fix.
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #4 from Bill Long --- Original submitter is looking for a fix version for this issue. Any predictions?
[Bug fortran/95037] gfortran fails to compile a simple subroutine, issues an opaque message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95037 --- Comment #4 from Bill Long --- Original submitter is interested in knowing what GCC version will have this fix.
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #4 from Bill Long --- The customer has nuclear weapons. They do not do "bounty". :) Cray/HPE is just the messenger. I think they would be happy with a plan for including the routine.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #5 from Bill Long --- The original intent of adding the KIND argument was because some implementations used a 32-bit integer for the result, and it is possible for the answer to be larger than 2**31-1. Just checking to be sure that the underlying library code returns a 64-bit integer that can later be converted based on the KIND value.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #19 from Bill Long --- On an ia64 Intel target that does not support x87 floating point, it seems that having IEEE_SUPPORT_DATATYPE (1._10) return .true. is as error. If that is fixed, will the rest of the issue fall into place?
[Bug fortran/95644] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #2 from Bill Long --- Any update on a fix for this? (The original customer is asking.)
[Bug fortran/97272] New: Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 Bug ID: 97272 Summary: Wrong answer from MAXLOC with character arg Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- Test case: > cat test.f90 program test character, allocatable :: a(:) integer(8) l, i l = 200_8 allocate (a(l)) do i = 1, l a(i) = 'a' end do l = l - 1 a(l) = 'b' i = maxloc (a, dim=1, kind=8) print *, 'i = ', i, 'a(i) = ', a(i) end Expected behavior (Cray): > ftn test.f90 > ./a.out i = 199 a(i) = b Incorrect result (gfortran): > module swap PrgEnv-cray PrgEnv-gnu > gfortran test.f90 > ./a.out i = 200 a(i) = a > gfortran --version GNU Fortran (GCC) 10.1.0 20200507 (Cray Inc.) Copyright (C) 2020 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.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #11 from Bill Long --- I checked with the Intel docs and the ia64 version of the compiler (what HPC users use) does not support x87. Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an error), to match the other compilers?
[Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 Bug ID: 95647 Summary: operator(.eq.) and operator(==) treated differently Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program test use, intrinsic :: ieee_arithmetic, only : & &ieee_class, & &ieee_class_type, & &ieee_negative_normal, & &ieee_positive_normal, & &operator(.eq.) ! use, intrinsic :: ieee_arithmetic real(4) r4 type(ieee_class_type) class1 r4 = 1.0 class1 = ieee_class(r4) if (class1 .eq. ieee_positive_normal) print *, 'yes' r4 = -1.0 class1 = ieee_class(r4) if (class1 .eq. ieee_negative_normal) print *, 'yes' end program test Try test.f90 with 3 compilers: > ftn test.f90 ./a.out yes yes > module swap PrgEnv-cray PrgEnv-intel > ifort test.f90 > ./a.out yes yes > module swap PrgEnv-intel PrgEnv-gnu > gfortran test.f90 test.f90:6:43: 6 | & ieee_positive_normal, & 1 Error: Intrinsic operator '.eq.' referenced at (1) not found in module 'ieee_arithmetic' test.f90:13:18: 13 | if (class1 .eq. ieee_positive_normal) print *, 'yes' 1 Error: Operands of comparison operator '.eq.' at (1) are TYPE(ieee_class_type)/TYPE(ieee_class_type) test.f90:16:18: 16 | if (class1 .eq. ieee_negative_normal) print *, 'yes' 1 Error: Operands of comparison operator '.eq.' at (1) are TYPE(ieee_class_type)/TYPE(ieee_class_type) Alternate test case: > diff test.f90 test1.f90 7c7 < &operator(.eq.) --- > &operator(==) Works better: > ftn test1.f90 > ./a.out yes yes > module swap PrgEnv-cray PrgEnv-intel > ifort test1.f90 > ./a.out yes yes > module swap PrgEnv-intel PrgEnv-gnu > gfortran test1.f90 > ./a.out yes yes Referencing .eq. or == should have the same effect. Curiously, the case that works is the one where the USE ONLY clause specifies operator(==) and the statements that reference that operator are written using .eq.
[Bug fortran/95644] New: IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 Bug ID: 95644 Summary: IEEE_FMA is missing from the IEEE_ARITHMETIC module Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test2.f90 program test use, intrinsic :: ieee_arithmetic, only : ieee_fma implicit none end program test Intel: > ifort test2.f90 Cray: > module swap PrgEnv-intel PrgEnv-cray > ftn test2.f90 > ./a.out gfortran: > module swap PrgEnv-cray PrgEnv-gnu > gfortran test2.f90 test2.f90:2:43: 2 | use, intrinsic :: ieee_arithmetic, only : ieee_fma 1 Error: Symbol 'ieee_fma' referenced at (1) not found in module 'ieee_arithmetic' >
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #6 from Bill Long --- (In reply to kargl from comment #3) > (In reply to Bill Long from comment #0) > > > cat test.f90 > > > Gfortran: > > > > > module swap PrgEnv-intel PrgEnv-gnu > > > gfortran test.f90 > > > ./a.out > > selected_real_kind(16) = 10 > > ieee_selected_real_kind(16) = 10 > > > > The output from gfortran is problematic because ieee_selected_real_kind > > should not return 10. If the users want KIND=10 (i.e. the > > Intel-proprietary 80-bit x87 floats), then they need to use > > selected_real_kind and not the IEEE version. > > IEEE-754 permits the extended double type (See 3.7 Extended and > extendable precisions). I do not see in the Fortran standard that > the output from ieee_seleted_real_kind must select binary32, > binary64, or binary128. > > That said, ieee_selected_real_kind is completely broken. > See PR69101. I used to have patch that fixed this PR, > but never got around to committing it. The patch attached > in 69101 is not correct. The description in the Fortran standard for IEEE_SELECTED_REAL_KIND includes "The result has a value equal to a value of the kind type parameter of an ISO/IEC/IEEE 60559:2011 floating-point format..." This, in practice, amounts to binary32, 64, 128 for RADIX=2 (the default). The 80-bit x87 format is not part of the quoted IEEE standard.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #5 from Bill Long --- The same user also submitted a bug about IEEE_FMA not being supported. Is there already a bug/rfe for that in the gcc bugzilla?
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #1 from Bill Long --- The main problem here is that selected_real_kind and ieee_selected_real_kind have different specifications. The ieee_selected_real_kind requires a KIND value corresponding to an IEEE floating format, whereas selected_real_kind is only limited to formats supported by the processor, including non-ieee formats, like the x87 80-bit format. (Which, apparently, even the Intel compiler no longer supports.) The expected output from gfortran would be > gfortran test.f90 > ./a.out selected_real_kind(16) = 10 ieee_selected_real_kind(16) = 16
[Bug fortran/95640] New: gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 Bug ID: 95640 Summary: gfortran ieee_selected_real_kind returns 10 Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program test use,intrinsic :: ieee_arithmetic print *, " selected_real_kind(16) = ", selected_real_kind(16) print *, "ieee_selected_real_kind(16) = ", ieee_selected_real_kind(16) end program test Cray: > ftn test.f90 > ./a.out selected_real_kind(16) = 16 ieee_selected_real_kind(16) = 16 Intel: > module swap PrgEnv-cray PrgEnv-intel > ifort test.f90 > ./a.out selected_real_kind(16) = 16 ieee_selected_real_kind(16) = 16 Gfortran: > module swap PrgEnv-intel PrgEnv-gnu > gfortran test.f90 > ./a.out selected_real_kind(16) = 10 ieee_selected_real_kind(16) = 10 The output from gfortran is problematic because ieee_selected_real_kind should not return 10. If the users want KIND=10 (i.e. the Intel-proprietary 80-bit x87 floats), then they need to use selected_real_kind and not the IEEE version.
[Bug fortran/95195] New: gfortran poorly handles a program error of writing a namelist to an unformatted file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95195 Bug ID: 95195 Summary: gfortran poorly handles a program error of writing a namelist to an unformatted file. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- gfortran poorly handles a program error of writing a namelist to an unformatted file. > cat test.f90 program test character(len=16) my_form character(len=240) msg data my_form /'unformatted'/ namelist /nml1/ i, j, k i = 1; j = 2; k = 3 open (unit=10, file='test.dat') write (10, nml=nml1) close (10) open (unit=10, file='test.dat', form=my_form) read (unit=10, nml=nml1) close (unit=10, status='delete') end program test > gfortran test.f90 > ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fadb087459f in ??? #1 0x7fadb15bf69e in fbuf_getc at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/fbuf.h:78 #2 0x7fadb15bf69e in next_char_default at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/list_read.c:215 #3 0x7fadb15bf69e in next_char_default at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/list_read.c:207 #4 0x7fadb15c8db7 in finalize_transfer at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/transfer.c:4109 #5 0x400bf7 in ??? #6 0x400c7c in ??? #7 0x7fadb085f349 in ??? #8 0x400779 in ??? at ../sysdeps/x86_64/start.S:120 #9 0x in ??? Segmentation fault (core dumped) > gfortran --version GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.) Copyright (C) 2019 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. A diagnostic message along the lines of the Cray or Intel compilers is preferred: > module swap PrgEnv-gnu PrgEnv-cray > ftn test.f90 > ./a.out lib-4080 : UNRECOVERABLE library error A formatted read or write is not allowed on an unformatted file. Encountered during a namelist READ from unit 10 Fortran unit 10 is connected to a sequential unformatted file: "test.dat" Aborted (core dumped) > module swap PrgEnv-cray PrgEnv-intel > ifort test.f90 > ./a.out forrtl: severe (257): formatted I/O to unit open for unformatted transfers, unit 10, file //test.dat Image PC Routine Line Source a.out 0040546B Unknown Unknown Unknown a.out 0041EF5E Unknown Unknown Unknown a.out 00402C31 Unknown Unknown Unknown a.out 00402A12 Unknown Unknown Unknown libc-2.26.so 7FC2FABAF34A __libc_start_main Unknown Unknown a.out 0040292A Unknown Unknown Unknown
[Bug fortran/95191] New: Hang in WAIT with a bad ID= value if threading specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95191 Bug ID: 95191 Summary: Hang in WAIT with a bad ID= value if threading specified Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program test real a(1) integer my_id integer bad_id data my_id /1/ data bad_id /2/ a = 1. open (unit=10, file='test.dat', form='unformatted', & &asynchronous='yes') write (unit=10, asynchronous='yes', id=my_id) a wait (unit=10, id=bad_id) close (unit=10, status='delete') end program test If there are no command line options for the compile, there is no issue. However, if -fopenmp is added (or -lpthreads is added for the link), then the code hangs. > gfortran test.f90 > ./a.out > gfortran -fopenmp test.f90 > ./a.out ^C <<<<<<<<<<<-- hangs here. > gfortran --version GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.) Copyright (C) 2019 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. Original submitter says it hangs here: hang in __gthread_cond_wait.
[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 --- Comment #1 from Bill Long --- Appears to be a regression. The original submitter thinks it is hanging in __lll_lock_wait inside CLOSE. Th same hang can be observed if the references to omp_get_num_threads are removed, but you still compile with -fopenmp (even though there is no openmp in the code). Appears to be related to linking with -lpthreads.
[Bug fortran/95119] New: CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 Bug ID: 95119 Summary: CLOSE hangs when -fopenmp is specified in compilation Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test3.f90 program test integer,external :: omp_get_num_threads character(len=16) my_status open (unit=10, file='test.dat') print *, omp_get_num_threads() write (10, *) 'weird' rewind (10) read (10, *) my_status close (10) open (unit=10, file='test.dat') close (unit=10, status=my_status, iostat=ios) print *, ios close (10, status='delete') end program test Works fine with gfortran 8.3.0: > gfortran -fopenmp test3.f90 > ./a.out 1 5002 > Hangs with gfortran 9.3.0: > gfortran -fopenmp test3.f90 > ./a.out 1 5002 ^C > module avail gcc
[Bug fortran/95104] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 --- Comment #3 from Bill Long --- A comment from the original user: gfortran 8.3.0 appears to do the right thing. So perhaps a regression somewhere in the 9.x line?
[Bug fortran/95104] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 --- Comment #1 from Bill Long --- The program appears to be legal and should execute and print 0. The last paragraph of 12.7.2 WAIT statement (current Fortran standard) is Execution of a WAIT statement specifying a unit that does not exist, has no file connected to it, or is not open for asynchronous input/output is permitted, provided that the WAIT statement has no ID= specifier; such a WAIT statement does not cause an error or end-of-file condition to occur.
[Bug fortran/95104] New: Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 Bug ID: 95104 Summary: Segfault on a legal WAIT statement Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program test wait (10, iostat=ios) print *, ios close (10) end program test > gfortran test.f90 > ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f3f0334159f in ??? #1 0x4007f6 in ??? #2 0x4008c7 in ??? #3 0x7f3f0332c349 in ??? #4 0x4006f9 in ??? at ../sysdeps/x86_64/start.S:120 #5 0x in ??? Segmentation fault (core dumped) longb@jupiter:/cray/css/users/longb/spr/jira/22703> gfortran --version GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.) Copyright (C) 2019 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.
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #1 from Bill Long --- Note that for the greatly simplified test case > cat test3.f90 real(4) function x (a) real(kind(x)) a(:) print *, kind(x) end function x gfortran compiles with no error. So maybe the issue boils down to the selection of the error message in the original test case.
[Bug fortran/95038] New: Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 Bug ID: 95038 Summary: Not treating function result name as a variable. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- Original test case from user: > cat test.f90 real(4) function x (a) real(kind(x)) a(:) interface if1 subroutine sub (a) real(kind(x)) a(:) end subroutine sub end interface if1 x = 0 end function x > cat test1.f90 function x (a) result(res) real(4) :: res real(kind(res)) a(:) interface if1 subroutine sub (a) real(kind(res)) a(:) end subroutine sub end interface if1 res = 0 end function x Second alternate test case: > cat test2.f90 real(4) function x (a) real(kind(x)) a(:) interface if1 subroutine sub (a) import :: x real(kind(x)) a(:) end subroutine sub end interface if1 x = 0 end function x Second alternate test case: > cat test2.f90 real(4) function x (a) real(kind(x)) a(:) interface if1 subroutine sub (a) import :: x real(kind(x)) a(:) end subroutine sub end interface if1 x = 0 end function x The original test.f90 and test1.f90 arguable need an IMPORT statement in the interface. However: > gfortran -c test2.f90 > gfortran -c test1.f90 > gfortran -c test.f90 test.f90:5:28: 5 | real(kind(x)) a(:) |1 Error: 'x' argument of 'kind' intrinsic at (1) must be a data entity test2 (the one with the IMPORT) compiles. But test1, without an IMPORT, fails to compile. It seems that gfortran is failing to recognize that the function name, when no RESULT clause is specified , is the name of a local variable.
[Bug fortran/95037] New: gfortran fails to compile a simple subroutine, issues an opaque message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95037 Bug ID: 95037 Summary: gfortran fails to compile a simple subroutine, issues an opaque message Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 subroutine my_random_seed_v (size, put, get) integer, optional :: size integer, optional :: put(1) integer, optional :: get(1) call random_seed (size, put, get) end subroutine my_random_seed_v Works with Cray compiler: > ftn -c test.f90 > module swap PrgEnv-cray PrgEnv-gnu Fails with gfortran: > gfortran -c test.f90 (null):0: confused by earlier errors, bailing out > gfortran --version GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.) Copyright (C) 2019 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. Original user was "confused" by the message, especially since there were no "earlier errors" output.
[Bug fortran/94738] New: C descriptor passed to Fortran from C apepars to have wrong type information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94738
Bug ID: 94738
Summary: C descriptor passed to Fortran from C apepars to have
wrong type information.
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat main.c
#include
#include
#include "ISO_Fortran_binding.h"
int main (int argc, char *argv[]) {
int ret;
int line;
int my_errno;
int i;
CFI_CDESC_T(1) cdesc;
CFI_rank_t rank = 1;
int version = CFI_VERSION;
CFI_attribute_t attribute = CFI_attribute_allocatable;
CFI_type_t typ = CFI_type_double;
CFI_index_t extents[rank];
CFI_index_t lower_bounds[rank];
CFI_index_t upper_bounds[rank];
size_t elem_len; // value doesn't matter
void sub (CFI_cdesc_t *);
for (i = 0; i < rank; i++) {
extents[i] = 100;
lower_bounds[i] = 1;
upper_bounds[i] = 100;
}
ret = CFI_establish ((CFI_cdesc_t *), 0, attribute, typ, elem_len, rank,
extents);
if (ret != CFI_SUCCESS) {
line = __LINE__;
goto done;
}
ret = CFI_allocate ((CFI_cdesc_t *), lower_bounds, upper_bounds,
elem_len);
if (ret != CFI_SUCCESS) {
line = __LINE__;
goto done;
}
sub ((CFI_cdesc_t *) );
line = 0;
done:
if (line != 0) {
asm ("hlt");
}
return 0;
}
> cat sub.f90
subroutine sub (a) bind (c)
use,intrinsic :: iso_c_binding
real(C_double), allocatable :: a(:)
do i = 1, size(a, 1)
a(i) = i
end do
print *, a
end subroutine sub
>
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
At line 7 of file sub.f90 (unit = 6, file = 'stdout')
Internal Error: list_formatted_write(): Bad type
It appears that the C descriptor, after being converted to a Fortran
descriptor, has the wrong type information encoded.
> cc --version
gcc (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 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.
> ftn --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 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.
Output from other compilers:
> module swap PrgEnv-gnu PrgEnv-cray
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14.,
15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27.,
28., 29., 30., 31., 32., 33., 34., 35., 36., 37., 38., 39., 40.,
41., 42., 43., 44., 45., 46., 47., 48., 49., 50., 51., 52., 53.,
54., 55., 56., 57., 58., 59., 60., 61., 62., 63., 64., 65., 66.,
67., 68., 69., 70., 71., 72., 73., 74., 75., 76., 77., 78., 79.,
80., 81., 82., 83., 84., 85., 86., 87., 88., 89., 90., 91., 92.,
93., 94., 95., 96., 97., 98., 99., 100.
> module swap PrgEnv-cray PrgEnv-intel
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
1.002.003.00
4.005.006.00
7.008.009.00
10.011.012.0
13.014.015.0
16.017.018.0
19.020.021.0
22.023.024.0
25.026.027.0
28.029.030.0
31.032.033.0
34.035.036.0
37.038.039.0
40.041.042.0
43.044.045.0
46.047.048.0
49.050.051.0
52.053.054.0
55.056.057.0
58.059.060.0
61.062.063.0
64.065.0
[Bug fortran/94411] E0.d not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 --- Comment #2 from Bill Long --- Thanks for the quick reply. Is there a predicted release date for 10.1?
[Bug fortran/94411] New: E0.d not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 Bug ID: 94411 Summary: E0.d not supported Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- We have a customer who complained that the Fortran 2018 feature for allowing w=0 in E-like format descriptors is not working with gfortran version 9.2. I pointed them to the table at https://gcc.gnu.org/wiki/Fortran2018Status and that the entry for "d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors" was marked "No" They pointed out that the other two compilers they commonly use (Cray and Intel) both support this feature. So, I'm submitting their "bug", but changing it to a RFE. With the hope that their input might help influence the priority given for this feature. Example test program: program test real(8) :: r r = atan(1.0) r = r * 65536 write (*,'(e0.6)') r end program test
[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248 --- Comment #5 from Bill Long --- Any progress on this?
[Bug fortran/88137] New: BACKTRACE seems to have a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137 Bug ID: 88137 Summary: BACKTRACE seems to have a memory leak Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- Simple test case from site: > cat test.f90 program test implicit none integer :: i do i= 1,1 call backtrace() enddo end program test Tracing memory usage with gfortran 4.9.3: Process Memory Details Virtual maximum (MB) 1.262 Resident maximum (MB) 0.930 Virtual at exit (MB) 1.258 Resident at exit (MB) 0.930 But with gfortran 8.2.0 Process Memory Details Virtual maximum (MB) 48282.594 Resident maximum (MB) 31592.816 Virtual at exit (MB) 48282.594 Resident at exit (MB) 31592.816 While the test case is artificial, it does illustrate that calls to backtrace seems to accumulate memory usage.
[Bug fortran/86248] LEN_TRIM in specification expression causes link failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248 --- Comment #1 from Bill Long --- Possibly related to 44265.
[Bug fortran/86248] New: LEN_TRIM in specification expression causes link failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248 Bug ID: 86248 Summary: LEN_TRIM in specification expression causes link failure Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat modu6.f90 module test_module implicit none public :: func_1 integer :: string_length = 3 character(len=*),parameter :: fixed_string = "el_" character(len=3),dimension(0:2),parameter :: darray_fixed = (/"el0","el1","el2"/) character(len=*),dimension(0:2),parameter :: darray = (/"el0","el1","el2"/) contains function func_1(func_1_input) !Declaration section integer, intent(in) :: func_1_input !Test6 character(len=len_trim(darray_fixed(func_1_input))) :: func_1 func_1=darray(func_1_input) end function func_1 end module test_module > cat test.f90 program test use test_module implicit none write(*,*) "Accessing Element index : ",0,"inside value : ",func_1(0) write(*,*) "Accessing Element index : ",1,"inside value : ",func_1(1) write(*,*) "Accessing Element index : ",2,"inside value : ",func_1(2) end program test > diff modu6.f90 modu8.f90 15c15 < character(len=len_trim(darray_fixed(func_1_input))) :: func_1 --- > character(len=len(darray_fixed(func_1_input))) :: func_1 > Using LEN in specification works as expected: > gfortran -c modu8.f90 > gfortran test.f90 modu8.o > ./a.out Accessing Element index :0 inside value : el0 Accessing Element index :1 inside value : el1 Accessing Element index :2 inside value : el2 Using LEN_TRIM instead of LEN fails: > gfortran -c modu6.f90 > gfortran test.f90 modu6.o /lus/scratch/tmp/ccljHL3g.o: In function `MAIN__': test.f90:(.text+0xaf): undefined reference to `__test_PROC_darray_fixed' test.f90:(.text+0x212): undefined reference to `__test_PROC_darray_fixed' test.f90:(.text+0x375): undefined reference to `__test_PROC_darray_fixed' collect2: error: ld returned 1 exit status
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #7 from Bill Long --- Thanks - very helpful information. I'll try to find out what version of gcc was used to build their library.
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #5 from Bill Long --- I tried on my Mac laptop (gcc version 6.3.0) and it also works there. Evidently not a representative test. The differences I see between that environment and the original customer's is that they are running 7.2.0, using srun (SLURM) for program launch, and running on Broadwell processors. The original error Internal Error: stash_internal_unit(): Stack Size Exceeded suggests some issue with running out of memory.
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #3 from Bill Long --- What happens with 16 threads?
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #1 from Bill Long --- The same code compiles and executes OK at 20 threads with other compilers. The size of the internal file is small (700 bytes).
[Bug libfortran/83948] New: Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 Bug ID: 83948 Summary: Thread safety issue writing to internal file - libgfortran Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 subroutine sub (a1, i1, f1, i2, i3, i4, out) implicit none character(30),intent(in) :: a1 integer,intent(in) :: i1, i2, i3, i4 real,intent(in) :: f1 character(700), intent(out) :: out character(700) :: local_out ! local stack variable write (local_out, "(A,A30,A,I8,A,I8,A,F8.6,A,I3,A,I3)") & "Same pole re-projecting area source: ", a1, & ': IndexVal=', i1, & ' Indexval*2=', i2, & ' RandomValue=', f1, & ", RandomValue*999=", i3, & ", iThread=", i4 out = local_out end subroutine sub program test use omp_lib implicit none integer,parameter :: n = 1000, cn = 700 character(cn) :: table(n) character(30) :: a1 integer :: i1, i2, i3, i4 real :: f1 integer :: i !$omp parallel do private (i1, i2, i3, i4, f1, a1) do i = 1,n call random_number(f1) i1 = min(i,) i2 = min(2*i, ) i3 = f1*999 i4 = omp_get_thread_num() a1 = "Beginnng of new record:" call sub (a1, i1, f1, i2, i3, i4, table(i)) end do !$omp end parallel do do i = max(1,n-5), n print *, "Table element number = ", i, trim(table(i)) end do end program test OK : 10 threads > export OMP_NUM_THREADS=10 > ftn -fopenmp -O3 test.f90 > srun -n1 -c10 ./a.out Table element number = 995 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 995 Indexval*2=1990 RandomValue=0.733033, RandomValue*999=732, iThread= 9 Table element number = 996 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 996 Indexval*2=1992 RandomValue=0.609290, RandomValue*999=608, iThread= 9 Table element number = 997 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 997 Indexval*2=1994 RandomValue=0.810925, RandomValue*999=810, iThread= 9 Table element number = 998 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 998 Indexval*2=1996 RandomValue=0.617685, RandomValue*999=617, iThread= 9 Table element number = 999 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 999 Indexval*2=1998 RandomValue=0.820912, RandomValue*999=820, iThread= 9 Table element number = 1000 Same pole re-projecting area source: Beginnng of new record: : IndexVal=1000 Indexval*2=2000 RandomValue=0.617121, RandomValue*999=616, iThread= 9 Fails: 20 threads > export OMP_NUM_THREADS=20 > srun -n1 -c20 ./a.out At line 15 of file test.f90 Internal Error: stash_internal_unit(): Stack Size Exceeded Error termination. Backtrace: #0 0x403ca0 in ??? #1 0x403e0f in ??? #2 0x4059cd in gomp_thread_start at ../../../cray-gcc-7.2.0-201709081833.7aac99f36ce61/libgomp/team.c:120 #3 0x41a263 in start_thread at /home/abuild/rpmbuild/BUILD/glibc-2.22/nptl/pthread_create.c:334 #4 0x4a1488 in ??? at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 #5 0x in ???
[Bug target/77897] Compile error with KNL & -O3 for GTC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897 --- Comment #4 from Bill Long --- Confirmation from the customer system: GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty.
[Bug target/77897] Compile error with KNL & -O3 for GTC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897 --- Comment #3 from Bill Long --- It would appear the customer system has > /usr/bin/as --version GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0
[Bug fortran/77897] Compile error with KNL & -O3 for GTC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897 --- Comment #1 from Bill Long --- Compiling these files appears to have a problem when the target is set to Intel KNL. The compiler appears to be generating incorrect register and instruction names, leading to assembler messages. See with gfortran 6.2. Compiles OK with any of these changes: 1) Change target to Sandybridge 2) Remove the -O3 option 3) Use a different vendor compiler (Cray)
[Bug fortran/77897] New: Compile error with KNL & -O3 for GTC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897 Bug ID: 77897 Summary: Compile error with KNL & -O3 for GTC code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- Created attachment 39767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39767=edit Source files module.F90 and pushe.f90 (in bug.tar) As a basic sanity check: > ftn -c module.F90 > ftn -c pushe.f90 > module swap PrgEnv-cray PrgEnv-gnu > ftn -c module.F90 > ftn -c pushe.f90 > ftn -c -O3 module.F90 > ftn -c -O3 pushe.f90 > > module list Currently Loaded Modulefiles: ... 12) gcc/6.2.0 13) craype-network-aries 14) craype-sandybridge Now checking KNL target: > module swap craype-sandybridge craype-mic-knl > ftn -c -O3 module.F90 > ftn -c -O3 pushe.f90 /tmp/cc4TRnzd.s: Assembler messages: /tmp/cc4TRnzd.s:61: Error: bad register name `%xmm24' /tmp/cc4TRnzd.s:63: Error: bad register name `%xmm24' /tmp/cc4TRnzd.s:65: Error: bad register name `%xmm16' ... [many more lines of messages]
[Bug fortran/68927] Code aborts in deallocate statement with a stat= specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927 --- Comment #3 from Bill Long --- Possibly related to pr59796, bun not a duplicate. In this example, the pointer being deallocated is associated. The problem is that it is associated with a target that cannot be deallocated. The standard says that this is an error condition (that must be caught by STAT=) and it is not a case of the program "shall not" do this. The program is technically standard conforming.
[Bug fortran/68927] Code aborts in deallocate statement with a stat= specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927 --- Comment #1 from Bill Long --- The DEALLOCATE statement in subroutine SUB is attempting to deallocate a static array with the SAVE attribute. The standard requires that a non-zero status be returned in cases like this, and execution continues without deallocating the offending array. In para 1 of 6.7.3.3 Deallocation of pointer targets, "Deallocating a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an error condition in the DEALLOCATE statement." Hence in this case, an error condition occurs. In para 3 of 6.7.4 STAT= specifier: "If any other error condition occurs during execution of the ALLOCATE or DEALLOCATE statement, the stat-variable becomes defined with a processor-dependent positive integer value different from STAT_STOPPED_IMAGE." Hence the value of IS is required to be non-zero. Error termination (crashing) is allowed only of STAT= is not specified. Example of expected behavior: > ftn test.f90 > ./a.out deallocate status: 4412
[Bug fortran/68927] New: Code aborts in deallocate statement with a stat= specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927 Bug ID: 68927 Summary: Code aborts in deallocate statement with a stat= specified Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program test use,intrinsic :: iso_c_binding real,target :: x(1000) real,pointer :: p (:) type(c_ptr) :: cp p => x cp = c_loc(p) call sub(cp) end program test subroutine sub(cp) use,intrinsic :: iso_c_binding real,pointer :: p(:) type(c_ptr) :: cp integer :: is call c_f_pointer(cp, p, [1000]) deallocate (p, stat=is) print *, "deallocate status: ", is end subroutine sub > gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/5.2.0/bin/../snos/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/5.2.0/snos/libexec/gcc/x86_64-suse-linux/5.2.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../cray-gcc-5.2.0/configure --prefix=/opt/gcc/5.2.0/snos --disable-nls --libdir=/opt/gcc/5.2.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/5.2.0/snos/include/g++ --with-slibdir=/opt/gcc/5.2.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog Thread model: posix gcc version 5.2.0 20150716 (Cray Inc.) (GCC) > gfortran test.f90 > ./a.out *** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0x7fff69364d90 *** === Backtrace: = /lib64/libc.so.6(+0x79098)[0x7f5f922e7098] ./a.out[0x4009c6] ./a.out[0x400aab] ./a.out[0x400ae2] /lib64/libc.so.6(__libc_start_main+0xe6)[0x7f5f9228cc36] ./a.out[0x4007b9] === Memory map: [many lines of output deleted]
[Bug fortran/64925] New: ICE with same names for dummy arg and internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925 Bug ID: 64925 Summary: ICE with same names for dummy arg and internal procedure Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com cat test.f90 subroutine foo(nnn, aaa, bbb, ccc) implicit none integer :: nnn, aaa, bbb(nnn) integer :: i do i=1,nnn aaa = aaa + bbb(ccc(i)) end do contains integer function ccc(i) implicit none integer :: i ccc = i end function ccc end subroutine foo gfortran -c test.f90 test.f90: In function 'foo': test.f90:1:0: internal compiler error: Segmentation fault subroutine foo(nnn, aaa, bbb, ccc) ^ 0x99c48f crash_signal ../../cray-gcc-4.9.2/gcc/toplev.c:337 0x687b03 create_function_arglist ../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:2142 0x68af6b gfc_create_function_decl(gfc_namespace*, bool) ../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:2585 0x68f689 gfc_generate_contained_functions ../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:4762 0x68f689 gfc_generate_function_code(gfc_namespace*) ../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:5589 0x62efe0 translate_all_program_units ../../cray-gcc-4.9.2/gcc/fortran/parse.c:4953 0x62efe0 gfc_parse_file() ../../cray-gcc-4.9.2/gcc/fortran/parse.c:5150 0x66c105 gfc_be_parse_file ../../cray-gcc-4.9.2/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Expected: Error message saying that a dummy argument and an internal procedure cannot have the same name in a scoping unit. (Both are class 1 local identifiers in subclause 16.3.1.)
[Bug fortran/64925] ICE with same names for dummy arg and internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925 --- Comment #2 from Bill Long longb at cray dot com --- The error message in Comment 1 provides correct information, and the compilation does not cause an ICE, so this is a definite improvement.
[Bug fortran/52075] OpenMP atomic update failing if -fbounds-check specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075 --- Comment #4 from Bill Long longb at cray dot com --- With this version: gfortran --version GNU Fortran (GCC) 4.9.1 20140716 (Cray Inc.) Copyright (C) 2014 Free Software Foundation, Inc. I see the following: gfortran -fopenmp -fbounds-check test.f90 ./a.out export OMP_NUM_THREADS=4 ./a.out FAIL - X( 16 ) == 11 (expected 15 ) STOP 1
[Bug fortran/61680] New: vectorization gives wrong answer for sandybridge target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61680 Bug ID: 61680 Summary: vectorization gives wrong answer for sandybridge target Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Created attachment 33056 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33056action=edit test3.f90 Bad result: gfortran -march=corei7-avx -O3 test3.f90 ./a.out 10.000 Good result: gfortran -march=corei7-avx -O3 -fno-tree-vectorize test3.f90 ./a.out 13.114877048604001 Version info: gfortran --version GNU Fortran (GCC) 4.9.0 20140422 (Cray Inc.) Copyright (C) 2014 Free Software Foundation, Inc.
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #14 from Bill Long longb at cray dot com --- Just a note that I'm now using $ gf --version GNU Fortran (MacPorts gcc49 4.9-20130609_0) 4.9.0 20130609 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. and the original test case works with this version.
[Bug fortran/55501] New: ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 Bug #: 55501 Summary: ICE using MERGE in constant expr Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com Test (extracted from a larger module) cat test2.f90 module test integer,parameter,private :: int32 = 4 integer,private,parameter :: dik = kind(0) ! Default Integer Kind type MPI_Datatype integer :: mpi_val end type type(MPI_Datatype),parameter,private :: MPIx_I4 = MPI_Datatype(4) type(MPI_Datatype),parameter,private :: MPIx_I8 = MPI_Datatype(8) type(MPI_Datatype),parameter :: MPI_INTEGER = merge(MPIx_I4, MPIx_I8, dik==int32) end module test ftn -c test2.f90 f951: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:5360 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Also fails with 4.8. Allowing MERGE here is a F2003 feature (elemental intrinsic with constant arguments). In any case, the compiler should not abort. Compiles OK with Cray compiler.
[Bug fortran/55501] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #1 from Bill Long longb at cray dot com 2012-11-28 00:37:14 UTC --- Plain integers in MERGE seem to be OK, so the problem appears to be with using constants of derived type as arguments to MERGE here.
[Bug fortran/54247] New: OpenMP code fails at execution in AMD Interlagos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247
Bug #: 54247
Summary: OpenMP code fails at execution in AMD Interlagos
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com
cat test.f90
! derived from OpenMP test omp31f/F31_A_16_1.F90
!based on Example A.16.1f, p. 213 lines 1-19 in OpenMP API Ver 3.1.
program F31_A_16_1
use omp_lib
implicit none
integer, parameter :: ITERATIONS = 2**17 ! Adjustable parameter
integer(kind=omp_lock_kind) :: lock
integer :: count_something_useful = 0, count_something_critical = 0
call omp_set_num_threads(16)
call omp_set_dynamic(.false.)
call omp_init_lock(lock)
!$omp parallel
!$omp single
call foo(lock, ITERATIONS)
!$omp end single
!$omp end parallel
if(count_something_useful /= ITERATIONS .or.
count_something_critical /= ITERATIONS) then
write (6, '(*(G0))') ' FAIL - ',
'(count_something_useful,count_something_critical) == (',
count_something_useful, ',', count_something_critical,
'), expected (', ITERATIONS, ',', ITERATIONS, ')'
end if
contains
! from OpenMP 3.1 Example A.16.1f
subroutine foo ( lock, n )
use omp_lib
integer (kind=omp_lock_kind) :: lock
integer n
integer i
do i = 1, n
!$omp task
call something_useful()
do while ( .not. omp_test_lock(lock) )
!$omp taskyield
end do
call something_critical()
call omp_unset_lock(lock)
!$omp end task
end do
end subroutine
subroutine something_useful()
!$omp atomic update
count_something_useful = count_something_useful+1
end subroutine something_useful
subroutine something_critical
! isn't necessary to protect with atomic update, as invocations of this
! subroutine are protected by a lock
count_something_critical = count_something_critical+1
end subroutine something_critical
end program F31_A_16_1
ftn -fopenmp test.f90
ilrun -n1 -d16 ./a.out
FAIL - (count_something_useful,count_something_critical) == (131072,131070),
expected (131072,131072)
Application 8535547 resources: utime ~6s, stime ~1s
mcrun -n1 -d16 ./a.out
Application 8535554 resources: utime ~0s, stime ~1s
The code triggers a FAIL trap on interlagos processors, but not on the previous
generation Magny-Cours AMD chips.
Command explanation:
ilrun -n1 -d16
-- Execute on a node with Interlagos processors, 1 node, 16 threads
mcrun -n1 -d16
-- Execute on a node with Magny-Cours processors, 1 node, 16 threads [2
sockets in SMP node]
ftn
-- wrapper for Cray systems to get the right (we hope) set of libraries and
default options for the current compilation environment. For the gcc
environment, the options implied are here are COLLECT_GCC_OPTIONS='-u'
'pthread_mutex_trylock' '-fno-second-underscore' '-march=bdver1' '-static' '-v'
'-fopenmp'
[Bug fortran/54247] OpenMP code fails at execution in AMD Interlagos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247 Bill Long longb at cray dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Bill Long longb at cray dot com 2012-08-13 20:38:33 UTC --- Our internal OpenMP gurus spotted that in line 36 the !$omp task should be !$omp task default(shared) With that change, the code executes correctly on Interlagos nodes. Conclusion is that there is a bug in the OpenMP 3.1 examples, so still potentially useful information. But the initial complaint is not valid.
[Bug fortran/52403] New: coarray component gives error with CLASS( ) declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52403 Bug #: 52403 Summary: coarray component gives error with CLASS( ) declaration Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com Possible another case that needs to be considered in Bug 52052 cat test.f90 module m_coarray implicit none private type, public :: coarray_t integer, allocatable, private :: value(:)[:] contains procedure :: allocate_myCoarray = allocate_myCoarray_sub end type contains subroutine allocate_myCoarray_sub(this) class(coarray_t), intent(inout) :: this allocate( this%value(num_images())[*] ) end subroutine end module !=== program main use m_coarray implicit none type(coarray_t) :: caf end program ftn -fcoarray=single test.f90 test.f90:14.43: class(coarray_t), intent(inout) :: this 1 Error: Component '_data' at (1) with coarray component shall be a nonpointer, nonallocatable scalar test.f90:14.43: class(coarray_t), intent(inout) :: this 1 Error: Component '_def_init' at (1) with coarray component shall be a nonpointer, nonallocatable scalar test.f90:14.43: class(coarray_t), intent(inout) :: this 1 Error: Component '_def_init' at (1) with coarray component shall be a nonpointer, nonallocatable scalar test.f90:16.14: allocate( this%value(num_images())[*] ) 1 Error: Coindexed allocatable object at (1) test.f90:21.15: use m_coarray 1 Fatal Error: Can't open module file 'm_coarray.mod' for reading at (1): No such file or directory I suspect the CLASS declaration is triggering come sort of hidden parent component that fails the requirements. Also fails with gfortran 4.7. Compiles without error with Cray and Intel compilers. I suspect this is just a case of incomplete implementation at this stage.
[Bug fortran/52075] New: OpenMP atomic update failing if -fbounds-check specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075
Bug #: 52075
Summary: OpenMP atomic update failing if -fbounds-check
specified
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com
Test code:
! derived from OpenMP test OMP3f/F03_2_8_5_3.F90
program F03_2_8_5_3
! thread-num n sets bit 2**n in each element of the array (assuming 2**n can
! be represented by the data type). Each element of the array should contain
! 2**num-threads - 1.
use omp_lib
implicit none
integer, parameter :: NT = 4
integer, parameter :: ARRAY_SIZE = 1024
integer :: X(ARRAY_SIZE) = 0, v, i
call omp_set_dynamic(.false.);
call omp_set_num_threads(NT);
!$omp parallel private(v)
if (omp_get_thread_num() STORAGE_SIZE(X)) then
do i = 1, ARRAY_SIZE
!$omp atomic
X(i) = IOR(X(i), 2**omp_get_thread_num())
end do
end if
!$omp end parallel
do i = 1, ARRAY_SIZE
if (X(i) /= MASKR(MIN(NT, STORAGE_SIZE(X then
write (*,*) 'FAIL - X(', i, ') == ', X(i), ' (expected ',
MASKR(MIN(NT, STORAGE_SIZE(X))),')'
stop 1
end if
end do
end program F03_2_8_5_3
Works as expected with just -fopenmp:
ftn -fopenmp test.f90
aprun -n1 -d4 ./a.out
Application 6244707 resources: utime ~0s, stime ~0s
Failing (wrong answer) if -fbounds-check is also specified:
ftn -fopenmp -fbounds-check test.f90
aprun -n1 -d4 ./a.out
FAIL - X( 1 ) ==7 (expected 15 )
STOP 1
Application 6244710 exit codes: 1
Application 6244710 resources: utime ~0s, stime ~0s
[Bug fortran/51815] New: confusing substring syntax with array section for character coarray
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51815 Bug #: 51815 Summary: confusing substring syntax with array section for character coarray Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com For this test: cat test.f90 PROGRAM caf_test_P0201R implicit none character(10) :: s[*] character(18) :: d = 'ABCDEFGHIJKLMNOPQR' integer :: img img = this_image() s = d(img:img+9) print *, img, s print *, img, s(2:4) END PROGRAM gfortran -fcoarray=single test.f90 test.f90:10.18: print *, img, s(2:4) 1 Error: Rank mismatch in array reference at (1) (1/0) The character variable s is not an array. The compiler appears to be confusing the substring syntax with an array section. Subclause 6.4.1 [118:9-15] indicates that this is allowed syntax. (coindexed parent-string)
[Bug fortran/51815] confusing substring syntax with array section for character coarray
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51815 --- Comment #1 from Bill Long longb at cray dot com 2012-01-10 19:34:58 UTC --- The (coindexed parent-string) bit at the end of the last line of the Description does not apply here. It's just a scalar-variable-name here as the parent-name.
[Bug fortran/51591] New: Strange output from STOP statement in OpenMP region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591
Bug #: 51591
Summary: Strange output from STOP statement in OpenMP region
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com
cat testc.c
#include unistd.h
/* extern unsigned int sleep (unsigned int __seconds); */
int sleepc_ (unsigned int *sec)
{
sleep(*sec);
return 0;
}
cat test.f90
use omp_lib
implicit none
integer i
print *,Hello World
call omp_set_num_threads(5)
!$omp parallel
!$omp do schedule(static,1)
do i=1,omp_get_num_threads()
!$omp critical
print *, I am,omp_get_thread_num(), of,omp_get_num_threads()
!$omp end critical
select case (omp_get_thread_num())
case (0)
call sleep (1)
stop 0
case (1)
stop 1
case (2)
stop 2
case (3)
stop 3
case default
stop
end select
enddo
!$omp end do
!$omp barrier
!$omp end parallel
end
cc -c testc.c
ftn -fopenmp test.f90 testc.o
Sometimes output looks OK:
aprun -n1 -d5 ./a.out
Hello World
STOP 1
I am 1 of 5
I am 2 of 5
Application 5777837 exit codes: 1
Application 5777837 resources: utime ~0s, stime ~0s
But more often there is some garbled text output:
aprun -n1 -d5 ./a.out
Hello World
STOP 1
I am 1 of 5
0im `m5 - What's this?
Application 5777838 exit codes: 1
Application 5777838 resources: utime ~0s, stime ~0s
Nice to see that the STOP 1 results in an exit code of 1, though - new F08
feature.
[Bug fortran/50692] New: option -finstrument-functions causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50692 Bug #: 50692 Summary: option -finstrument-functions causes ICE Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com cat test1.F program hello include 'mpif.h' integer rank, size call MPI_INIT(ierr) call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) call MPI_COMM_SIZE(MPI_COMM_WORLD, size, ierr) print *, Hello from process , rank, of , size, ! call MPI_FINALIZE(rc) stop end ftn -finstrument-functions test1.F test1.F: In function 'main': test1.F:16:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Appears to be a regression - OK with 4.5.3.
[Bug fortran/50570] New: Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570 Bug #: 50570 Summary: Incorrect error for assignment to intent(in) pointer Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com cat test.f90 program bots_sparselu_pointer_intent_in ! derived from Fortran trans of BOTS sparselu implicit none integer, pointer :: array(:) allocate(array(4)) array = 0 call sub(array) write (*,*) SUM(array) contains subroutine sub(dummy) integer, pointer, intent(in) :: dummy(:) dummy(1) = 1 ! note that gfortran 4.6.1 accepts dummy = 1 end subroutine sub end program bots_sparselu_pointer_intent_in gfortran -c test.f90 test.f90:16.5: dummy(1) = 1 ! note that gfortran 4.6.1 accepts dummy = 1 1 Error: Dummy argument 'dummy' with INTENT(IN) in variable definition context (assignment) at (1) This should compile. In the case of a POINTER dummy, the INTENT(IN) applies to the pointer association status, not definition of the target. Appears to be a regression, as 4.5.3 was OK.
[Bug fortran/50201] New: gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 Bug #: 50201 Summary: gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com It appears that the combination of -static and promoting 'double precision' to kind=16 causes problems for writing an double precision array. Either changing from array to scalar, or removing -static avoids the problem. Writing quad scalar with -static is fine: cat fdp2.f90 double precision :: x x = 3.4 print *, kind(x) write (*, (f10.3) ) x end gfortran -fdefault-real-8 -static fdp2.f90 ./a.out 16 3.400 Writing quad array with -static - segfault. cat fdp1.f90 double precision :: x(4) x = 3.4 print *, kind(x) write (*, (4f10.3) ) x end gfortran -fdefault-real-8 -static fdp1.f90 ./a.out 16 Segmentation fault But is OK without -static: gfortran -fdefault-real-8 fdp1.f90 ./a.out 16 3.400 3.400 3.400 3.400
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #2 from Bill Long longb at cray dot com 2011-08-26 21:00:04 UTC --- OS is Linux SLES 11. From the output in the test, it looks like you tried only the scalar case, which I agree works. The array case (second test code) is the one the fails.
[Bug fortran/49693] Spurious unused-variable warnings for COMMON block module variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693 Bill Long longb at cray dot com changed: What|Removed |Added CC||longb at cray dot com --- Comment #1 from Bill Long longb at cray dot com 2011-08-12 19:22:50 UTC --- Had a user support with similar issues when using the MPI module. Test case: module dmi_mpi_global use mpi implicit none private logical,save, public :: debug_print integer(4), save, public :: iu06 integer(4), save, public :: mpi_io_rank = 0 character(LEN=256), save, public :: mpi_decomp_file = 'mpi_decompo.txt' public :: dmpi_close contains subroutine dmpi_close ( flag ) implicit none logical, intent(in) :: flag integer(4) :: ierr if (flag) then write(*,'(a19)') 'Time to die for MPI' else write(iu06,'(a19)') 'Time to die for MPI' endif if (.not.flag) close (iu06) call mpi_finalize(ierr) end subroutine dmpi_close end module dmi_mpi_global ftn -c -Wall test.f90 test.f90:2:0: warning: 'mpi_bottom' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_in_place' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_status_ignore' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_statuses_ignore' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_errcodes_ignore' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_unweighted' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_argvs_null' defined but not used [-Wunused-variable] test.f90:2:0: warning: 'mpi_argv_null' defined but not used [-Wunused-variable]
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Bill Long longb at cray dot com changed: What|Removed |Added CC||longb at cray dot com --- Comment #6 from Bill Long longb at cray dot com 2011-07-22 17:53:49 UTC --- Since most other compilers support ieee_arithmetic now, the lack of support in gfortran is becoming a portability issue. Simple test case with 4.6.1: cat t1.f90 program test use,intrinsic :: ieee_arithmetic real :: x read *, x if (ieee_is_nan(x)) then print *, Nan else print *, Not NaN end if end program test gfortran t1.f90 t1.f90:2.35: use,intrinsic :: ieee_arithmetic 1 Fatal Error: Can't find an intrinsic module named 'ieee_arithmetic' at (1)
[Bug fortran/48894] New: generic omp_get_ancestor_thread_num(l(i)) produces incorrect output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48894 Summary: generic omp_get_ancestor_thread_num(l(i)) produces incorrect output Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com I wavered between minor and trivial on this one, but the OpenMP testers came up with this end case. It seems very unlikely to arise in a real program, but is also probably easy to fix in the library code. cat test1.f90 ! derived from OpenMP test OMP3f/F03_3_2_17_1a.F90 ! See - OpenMP 3.0 API spec, p. 131, lines 2-9. program F03_3_2_17_1a use omp_lib implicit none logical, parameter :: FALSE=.false. logical, parameter :: TRUE=.true. integer, parameter :: ZERO=0 integer, parameter :: TWO=2 integer*4, parameter :: ZERO4=0 integer, parameter :: MHUGE4=-huge(ZERO4) integer :: level(10) = (/-huge(ZERO), -huge(ZERO)+3, MHUGE4, -1, 0, 1, 2, 3, 4, huge(ZERO)/) integer :: i integer, dimension(10) :: expected_ancestor_thread_num, actual_ancestor_thread_num = (/(-huge(i), i=1,10)/) call omp_set_dynamic( FALSE ) call omp_set_nested( TRUE ) call omp_set_max_active_levels(TWO) ! one inactive parallel region ! if the implementation supports nested parallelism, then expected value of ! omp_get_ancestor_thread(2) == 1, else 0 if (omp_get_nested()) then expected_ancestor_thread_num = (/-1, -1, -1, -1, 0, 2, 1, 0, -1, -1/) else expected_ancestor_thread_num = (/-1, -1, -1, -1, 0, 2, 0, 0, -1, -1/) end if !$omp parallel num_threads(3)! nest level 1 if (omp_get_thread_num() == 2) then ! ancestor thread num = 2 at this level !$omp parallel num_threads(2) ! nest level 2 if ((omp_get_nested() .and. omp_get_thread_num() == 1) .or. (omp_get_nested() .eqv. .false. .and. omp_get_thread_num() == 0)) then !$omp parallel ! nest level 3 ! inactive parallel region due to max-active-level-var == 2, ! so should be executed by only one thread do i = 1, size(level) actual_ancestor_thread_num(i) =omp_get_ancestor_thread_num(level(i)) end do !$omp end parallel end if !$omp end parallel end if !$omp end parallel do i = 1, size(level) print *, 'level(i)=', level(i) if (actual_ancestor_thread_num(i) /= expected_ancestor_thread_num(i)) then print *, FAIL - omp_get_ancestor_thread_num(, level(i), ), == , actual_ancestor_thread_num(i), (expected , expected_ancestor_thread_num(i), ) end if end do end program F03_3_2_17_1a gfortran -fopenmp -fdefault-integer-8 -fdefault-real-8 test1.f90 ./a.out level(i)= -9223372036854775807 FAIL - omp_get_ancestor_thread_num( -9223372036854775807 ) == 2 (expected-1 ) level(i)= -9223372036854775804 level(i)= -2147483647 level(i)= -1 level(i)=0 level(i)=1 level(i)=2 level(i)=3 level(i)=4 level(i)= 9223372036854775807 From the OpenMP spec from page 131, lines 2-5: The omp_get_ancestor_thread_num routine returns the thread number of the ancestor at a given nest level of the current thread or the thread number of the current thread. If the requested nest level is outside the range of 0 and the nest level of the current thread, as returned by the omp_get_level routine, the routine returns -1. The routine omp_get_level() always returns a result that is 0 or a positive integer. So any negative argument to omp_get_ancestor_thread_num that is negative is outside the range 0..omp_get_level(), so the result should be -1. I suspect what is happening here is that the computation inside omp_get_ancestor_thread_num (n) involves a subtract of n - num_threads which wraps around because the value of n is at the limit of representable integers. Note that the second trial input is different by 3 (and num_threads is 3), so it just barely avoids the wrap.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #3 from Bill Long longb at cray dot com 2011-05-04 22:40:31 UTC --- On 5/4/11 3:28 AM, burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 (In reply to comment #1) [BIND(C) with OPTIONAL arguments] The Intel and PGI compilers already support this (no compile errors, correct output). Having a correct output is probably not surprising as most Fortran compilers already handle OPTIONAL internally by passing a NULL pointer. Thus, also for gfortran it would only a few lines (allowing it unless -std=f95/f2003/f2008 is specified - and rejecting with BIND(C) the combination of OPTIONAL with VALUE). I was thinking of introducing an flag -std=f2008tr, which will allow F2008 with the two TR, which are being drafted: TR 29113 and the coarray TR. Seems like a reasonable approach. PGI and Intel are nominally out of compliance since the current ban on BIND(C) and OPTIONAL is a constraint. Tying to compiler options is a way to avoid that issue. It's on my agenda (cf. PR 48820 and http://gcc.gnu.org/wiki/TR29113Status), but as it is a post-F2008 item, I thought I wait for the PDTR or FDTR and concentrate until then on, e.g., coarrays. Sounds like a good plan to me.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #1 from Bill Long longb at cray dot com 2011-05-03 21:51:29 UTC --- As an aside, the code in the Description is a work-around to avoid using the TR 29113 feature that allows Optional arguments. This would be the preferred code in the future: cat cknew1.f90 module graph_partitions use,intrinsic :: iso_c_binding interface subroutine Cfun (num, array) bind(c, name=Cfun) import :: c_int integer(c_int),value :: num integer(c_int),optional:: array(*) end subroutine Cfun end interface end module graph_partitions program test use graph_partitions integer(c_int) :: a(100) call Cfun (1, a) call Cfun (2) end program test The Intel and PGI compilers already support this (no compile errors, correct output). The Cray compiler also does if the NEW_FORTRAN environment variable is set (which just disables the error about having an OPTIONAL dummy in a BIND(C) interface). It is a separate issue from this BUG, but it might be a nice enhancement to enable the TR feature of allowing OPTIONAL arguments in BIND(C) interfaces. It appears that some other vendors have already jumped on that bandwagon.
[Bug fortran/48858] New: Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
Summary: Incorrect error for same binding label on two generic
interface specifics
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com
For this example code:
cat ck1.c
#include stdio.h
void Cfun ( int n, int *array){
if ( array == NULL )
printf ( call %d passes NULL as arg 2 \n, n);
else
printf ( call %d passes array address as arg 2 \n, n);
}
[The C part compiles fine.]
cat ck.f90
module graph_partitions
use,intrinsic :: iso_c_binding
interface Cfun
subroutine cfunc1 (num, array) bind(c, name=Cfun)
import :: c_int
integer(c_int),value :: num
integer(c_int) :: array(*)
end subroutine cfunc1
subroutine cfunf2 (num, array) bind(c, name=Cfun)
import :: c_int, c_ptr
integer(c_int),value :: num
type(c_ptr),value:: array
end subroutine cfunf2
end interface
end module graph_partitions
program test
use graph_partitions
integer(c_int) :: a(100)
call Cfun (1, a)
call Cfun (2, C_NULL_PTR)
end program test
I get
gcc -c ck1.c
gfortran ck.f90 ck1.o
ck.f90:11.22:
subroutine cfunf2 (num, array) bind(c, name=Cfun)
1
ck.f90:5.22:
subroutine cfunc1 (num, array) bind(c, name=Cfun)
2
Error: Binding label 'Cfun' in interface body at (1) collides with the global
entity 'Cfun' at (2)
ck.f90:20.22:
Same behavior for 4.5.2 and 4.6.0.
The same code compiles and executes fine with the Cray, Intel, and PGI
compilers. The expected output is:
./a.out
call 1 passes array address as arg 2
call 2 passes NULL as arg 2
This code should compile. There is only one entity with the binding lablel
Cfun. In the words in the standard, only one entity of the program with
this binding label. The names cfunc2 and cfunc1 are both local identifiers.
(Sections 16.2 and 16.3).
This construction is specifically allowed in the standard to allow users to
call a C function with multiple interfaces, similar to what is illustrated
here.
[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48174
--- Comment #4 from Bill Long longb at cray dot com 2011-03-18 16:08:37 UTC
---
Additional comment from originator of the bug at Cray:
The DIE tag DW_TAG_unspecified_parameters indicates that a variable argument
list starts. Try a simple C program for contrast. Just create x.c
#include stdarg.h
int foo (int a, ...)
{
return a;
}
and do
gcc -c -g x.c
then
readelf -wip x.o
and you'll see a subprogram, followed by the first formal parameter, then the
unspecified parameters. This doesn't seem to make sense in the Fortran context.
...
137: Abbrev Number: 4 (DW_TAG_subprogram)
38 DW_AT_external: 1
39 DW_AT_name: foo
3d DW_AT_decl_file : 1
3e DW_AT_decl_line : 4
3f DW_AT_prototyped : 1
40 DW_AT_type: 0x6b
44 DW_AT_low_pc : 0x0
4c DW_AT_high_pc : 0x91
54 DW_AT_frame_base : 0x0(location list)
58 DW_AT_sibling : 0x6b
25c: Abbrev Number: 5 (DW_TAG_formal_parameter)
5d DW_AT_name: a
5f DW_AT_decl_file : 1
60 DW_AT_decl_line : 3
61 DW_AT_type: 0x6b
65 DW_AT_location: 3 byte block: 91 bc 7e (DW_OP_fbreg: -196)
269: Abbrev Number: 6 (DW_TAG_unspecified_parameters)
[Bug fortran/48174] New: DWARF for subroutine with no args indicates 'varargs'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48174 Summary: DWARF for subroutine with no args indicates 'varargs' Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com cat test.f MODULE swim_arrays REAL, DIMENSION(:,:), ALLOCATABLE :: U END MODULE SUBROUTINE ALLOC_ARRAYS USE swim_arrays INTEGER N1,N2 PARAMETER (N1=513, N2=4097) INTEGER status ALLOCATE(U(N1,N2), STAT=status) END SUBROUTINE gfortran -g -O2 -c test.f objdump --dwarf test.o 12d: Abbrev Number: 2 (DW_TAG_subprogram) 2e DW_AT_external: 1 2f DW_AT_name: (indirect string, offset: 0x0): alloc_arrays 33 DW_AT_decl_file : 1 34 DW_AT_decl_line : 5 35 DW_AT_low_pc : 0x0 3d DW_AT_high_pc : 0x83 45 DW_AT_frame_base : 0x0(location list) 49 DW_AT_sibling : 0x79 24d: Abbrev Number: 3 (DW_TAG_unspecified_parameters) . The DWARF information (DW_TAG_unspecified_parameters) for subroutine alloc_arrays above is showing that the subroutine has a variable number of arguments. This is causing failures in performance tools that use this information.
[Bug fortran/48117] New: ICE: OpenMP; in build_int_cst_wide, at tree.c:1178
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117 Summary: ICE: OpenMP; in build_int_cst_wide, at tree.c:1178 Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com cat test.f90 MODULE mo_real_timer IMPLICIT NONE PRIVATE PUBLIC :: get_new_timer INTEGER, PARAMETER :: timer_max = 1024 INTEGER :: top_timer = 0 ! shared part of timer TYPE srt_type LOGICAL :: reserved ! usage flag CHARACTER(len=80) :: text ! description of timer END TYPE srt_type ! thread private part of timer TYPE(srt_type), PARAMETER :: srt_init = srt_type(.FALSE., 'noname') TYPE(srt_type) :: srt(timer_max) CONTAINS SUBROUTINE get_new_timer(itimer, text) INTEGER, VOLATILE, INTENT(inout):: itimer ! itimer should not be threadprivate CHARACTER(len=*), INTENT(in), OPTIONAL :: text ! works like new_timer(), ! but can be called from within a parallel region !$OMP MASTER IF (PRESENT(text)) srt(top_timer)%text = adjustl(text) !$OMP END MASTER END SUBROUTINE get_new_timer END MODULE mo_real_timer gfortran -c -O2 test.f90 gfortran -c -fopenmp test.f90 gfortran -c -fopenmp -O2 test.f90 test.f90: In function 'get_new_timer': test.f90:22:0: internal compiler error: in build_int_cst_wide, at tree.c:1178 ... gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/4.5.2/bin/../snos/bin/gfortran ... Thread model: posix gcc version 4.5.2 20101216 (Cray Inc.) (GCC) Compiles OK with either -O2 or -fopenmp, but ICE when both used together.
[Bug fortran/47886] New: ICE: OpenMP !$omp task if(omp_get_num_threads() 0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47886 Summary: ICE: OpenMP !$omp task if(omp_get_num_threads() 0) Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com Test code: ! derived from OpenMP test OMP3f/F03_2_7_1d.F90 program F03_2_7_1d use omp_lib implicit none integer, parameter :: NT = 4 integer :: sum = 0 call omp_set_num_threads(NT); !$omp parallel !$omp task if(omp_get_num_threads() 0) !$omp atomic sum = sum + 1 !$omp end task !$omp end parallel if (sum /= NT) then print *, FAIL - sum == , sum, (expected , NT, ) stop 1; end if end program F03_2_7_1d gfortran -fopenmp test.f90 test.f90: In function 'f03_2_7_1d': test.f90:11:0: internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:1368 Please submit a full bug report, gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/4.5.2/bin/../snos/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/4.5.2/snos/libexec/gcc/x86_64-suse-linux/4.5.2/lto-wrapper Target: x86_64-suse-linux Same code fine with ifort: ifort -openmp test.f90 ./a.out
[Bug fortran/40876] OpenMP private variable referenced in a statement function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876 --- Comment #8 from Bill Long longb at cray dot com 2010-12-27 01:42:20 UTC --- I am out of the office until Monday, January 3, 2011. Send technical questions to spsl...@cray.com.
