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