[Bug fortran/56994] New: Incorrect documentation for Fortran NEAREST intrinsic function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56994 Bug #: 56994 Summary: Incorrect documentation for Fortran NEAREST intrinsic function Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: spam.brian.tay...@gmail.com The GNU Fortran documentation** for the Fortran intrinsic function NEAREST(X,S) says that S is an optional argument. It is not optional according to the Fortran standard. It is implemented correctly in gfortran, so this is only an error in the documentation. ** http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gfortran/NEAREST.html
[Bug fortran/54695] New: Bogus warning for module variable in USE statement with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54695 Bug #: 54695 Summary: Bogus warning for module variable in USE statement with -Wall Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: spam.brian.tay...@gmail.com Created attachment 28263 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28263 Fortran source file that generates bogus warning when compiled with -Wall When compiled with -Wall, gfortran gives a bogus warning with the attached code. Clearly, the module variable "b" has not been imported, yet gfortran warns about it being explicitly imported. This only seems to be triggered by module variables that are stored in common blocks. user@host $ gfortran-4.7 -Wall -c bogus_warning.f90 bogus_warning.f90:8.4: use mod, only: a 1 Warning: Unused module variable 'b' which has been explicitly imported at (1) user@host $ gfortran-4.7 --version GNU Fortran (GCC) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. user@host $ uname -a Darwin MBP.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
[Bug fortran/57328] New: Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Bug ID: 57328 Summary: Missed optimization: Unable to vectorize Fortran min and max intrinsics Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Created attachment 30145 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30145&action=edit Test case for vectorization of loops containing max and if Use of the Fortran min or max intrinsic functions within a loop appears to prevent vectorization of the loop. Replacement of min or max with conditional assignment using if statements allows vectorization. A simple test case using max is attached. If compiled with "gfortran -O2 -msse2 -ftree-vectorize -ftree-vectorizer-verbose=1 -c max_vs_ifs_in_loop.F90", I get (with extraneous output snipped): ... max_vs_ifs_in_loop.F90:1: note: vectorized 0 loops in function. ... max_vs_ifs_in_loop.F90:17: note: LOOP VECTORIZED. ... gfortran should be able to vectorize loops containing min or max, using any number of arguments to these intrinsics, e.g. "tmp = max(r1, r2, r3, r4)". Compiler info: user@host $ gfortran --version GNU Fortran (GCC) 4.8.0 Copyright (C) 2013 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug fortran/51024] OpenMP: ICE with type(c_ptr) in private()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51024 --- Comment #2 from Brian Taylor --- This problem persists in gcc 4.8.0.
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 --- Comment #7 from Brian Taylor --- (In reply to Jakub Jelinek from comment #5) > But vectorization reorders the loop iterations, thus say if some value is > sNaN, you'd get exceptions in different order. So, I'm afraid without > -ffast-math you can vectorize this only if the user says that the order of > iterations doesn't matter (say using OpenMP 4.0 #pragma omp simd or Cilk+ > #pragma simd). I'm not sure this is actually a problem (or perhaps there is a another bug), because as I noted in the PR replacing min or max with a "functionally equivalent" sequence of if statements allows vectorization.
[Bug fortran/57423] New: Incorrect keyword argument names in Fortran OpenMP procedure interfaces in omp_lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57423 Bug ID: 57423 Summary: Incorrect keyword argument names in Fortran OpenMP procedure interfaces in omp_lib Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Created attachment 30197 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30197&action=edit Test omp_lib keyword arguments The argument names of many of the the OpenMP procedure interfaces in gfortran's omp_lib.f90 differ from those listed in the OpenMP 3.0 standard. Starting with Fortran 90, dummy argument names in procedures with explicit interfaces are, in a sense, part of the API. Section 3.1 of the OpenMP 3.0 standard defines the various procedure interfaces. For example, one should be able write code like: call omp_set_num_threads(num_threads=1) This does not work with the present implementation in omp_lib.f90, as the interface is declared with an argument named "set" rather than "num_threads". Page 108, line 18 of the OpenMP 3.0 standard states, "The OpenMP Fortran API runtime library routines are external procedures." However, lines 20-23 read, "Interface declarations for the OpenMP Fortran runtime library routines described in this chapter shall be provided in the form of a Fortran include file named omp_lib.h or a Fortran 90 module named omp_lib. It is implementation defined whether the include file or the module file (or both) is provided." It is perhaps arguable, then, if it is intended for keyword arguments to be part of the OpenMP Fortran interface, but if explicit interfaces are to be declared in omp_lib.f90, it can't hurt to make the implementation match up more closely with the standard. Of the procedures that take arguments declared in omp_lib.f90, only omp_set_schedule, omp_set_max_active_levels, omp_get_ancestor_thread_num, and omp_get_team_size have correct argument name(s). The attached test case illustrates these problems. It should be compiled with: gfortran -fopenmp -c openmp_keyword_arguments.F90
[Bug fortran/57423] Incorrect keyword argument names in Fortran OpenMP procedure interfaces in omp_lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57423 Brian Taylor changed: What|Removed |Added Severity|normal |trivial
[Bug fortran/77612] New: ICE on invalid character len in contained procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77612 Bug ID: 77612 Summary: ICE on invalid character len in contained procedure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Target Milestone: --- The following code causes gfortran 6.2.0 to ICE: user@host $ cat bad_len.f90 program bad_len implicit none contains subroutine sub() character(len = make_gfortran_ICE) :: line end subroutine end program user@host $ gfortran bad_len.f90 bad_len.f90:6:0: subroutine sub() internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1064 bad_len.f90:6:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Please submit a full bug report, with preprocessed source if appropriate. user@host $ gfortran --version GNU Fortran (Homebrew gcc 6.2.0 --without-multilib) 6.2.0 Copyright (C) 2016 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. If "implicit none" is commented out, gfortran stops with a reasonable error message: bad_len.f90:7:19: character(len = make_gfortran_ICE) :: line 1 Error: Variable 'make_gfortran_ice' cannot appear in the expression at (1)
[Bug fortran/65542] New: SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65542 Bug ID: 65542 Summary: SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Prior to the Fortran 2003 standard, only a subset of transformational intrinsic functions were allowed in initialization expressions (specifically: REPEAT, RESHAPE, SELECTED_INT_KIND, SELECTED_REAL_KIND, TRANSFER, and TRIM). See Fortran 95 ISO draft standard, section 7.1.6.1, lines 9-11, page 94. The following code should not compile with -std=f95: module bug integer :: ibug(42) = spread(42, 1, 42) end module
[Bug fortran/67039] New: Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 Bug ID: 67039 Summary: Documentation of pseudorandom number intrinsics is incorrect Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Target Milestone: --- The gfortran documentation for the RANDOM_NUMBER and RANDOM_SEED subroutines indicates that they are part of Fortran 95 and later. In fact, they were included in the Fortran 90 standard. The gfortran documentation for the SRAND subroutine, a GNU extension, includes in the "Notes" section the following: "The Fortran 2003 standard specifies the intrinsic RANDOM_SEED to initialize the pseudo-random numbers generator and RANDOM_NUMBER to generate pseudo-random numbers." The reference here should be to the Fortran 90 standard, not 2003. https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gfortran/RANDOM_005fNUMBER.html#RANDOM_005fNUMBER https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gfortran/RANDOM_005fSEED.html#RANDOM_005fSEED https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gfortran/SRAND.html#SRAND
