[Bug fortran/30554] [4.2 and 4.1 only] ICE in mio_pointer_ref at module.c:1945
--- Comment #7 from jellby at yahoo dot com 2007-02-02 09:26 --- The patch seems to fix the problem with the test file. Unfortunately, the original problem with the Dynamo package remains, I still get: gfortran -c -I./modules -J./modules -O3 -o objects/energy.o ./source/energy.F90 ./source/energy.F90:0: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug middle-end/30667] [4.3 Regression] ICE in immed_double_const, at emit-rtl.c:468
--- Comment #4 from jellby at yahoo dot com 2007-02-14 13:45 --- It's solved for me with gcc version 4.3.0 20070209 (it failed before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30667
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #12 from jellby at yahoo dot com 2007-03-14 09:04 --- I get the same error if I rewind the file (or is it illegal?): PROGRAM TEST INTEGER :: A OPEN(10, FORM="UNFORMATTED", RECL=1024) A = -1 WRITE(10) A REWIND(10) WRITE(10) A END PROGRAM TEST -- jellby at yahoo dot com changed: What|Removed |Added CC| |jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug fortran/31265] New: Error with RESHAPE on REAL initialization
With std f95 or f2003, "reshape" is not allowed in real arrays, but it is in integer ones or with std legacy or gnu. It seems the standard should actually allow this construct (see http://gcc.gnu.org/ml/fortran/2007-02/msg1.html), so here is a bug report (I didn't anything similar). $cat test.f90 PROGRAM test IMPLICIT NONE INTEGER, DIMENSION(3,3), PARAMETER :: & Aij=RESHAPE((/ 1,3,3, & 3,2,2, & 3,2,2 /), (/3,3/)) REAL, DIMENSION(3,3), PARAMETER :: & Bij=RESHAPE((/ 1.0D0,3.0D0,3.0D0, & 3.0D0,2.0D0,2.0D0, & 3.0D0,2.0D0,2.0D0 /), (/3,3/)) END PROGRAM test $gfortran -std=f95 -c test.f90 test.f90:9.8: Bij=RESHAPE((/ 1.0D0,3.0D0,3.0D0, & 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) -- Summary: Error with RESHAPE on REAL initialization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31265
[Bug fortran/31266] New: Spurious(?) warning about character truncation
When a component of a "custom" type is a character, taking a substring of it
triggers a warning about the variable being truncated (with -Wall). Maybe it is
not the correct syntax to get a substring out of a character component (still,
it works fine for printing, for example)?
$cat test.f90
PROGRAM test
IMPLICIT NONE
TYPE custom
CHARACTER(LEN=10) :: nom
END TYPE custom
CHARACTER (LEN=10) :: a
CHARACTER (LEN=2) :: b
TYPE(custom) :: c
a='1234567890'
b=a(1:2)
c%nom=a
b=c%nom(1:2)
END PROGRAM test
$gfortran -Wall -c test.f90
test1.f90:13.14:
b=c%nom(1:2)
1
Warning: rhs of CHARACTER assignment at (1) will be truncated (10/2)
--
Summary: Spurious(?) warning about character truncation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellby at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug regression/31383] New: ICE with -O2 -ftree-vectorize (regression)
I found this with gfortran (gcc version 4.3.0 20070328), it seems to work with the gfortran/gcc included in my Mandriva 2007 (gcc version 4.1.1 20060724), so I've marked it as a regression. $ cat test.f90 SUBROUTINE Test IMPLICIT NONE INTEGER :: i, j REAL*8 :: C(3,100), rM(100), rMI COMMON /RInfo/ rMI DO i = 1, 3 DO j = 1, 100 rMI = C(1,j) + C(i,j) END DO END DO END $ gfortran -c -O2 -ftree-vectorize test.f90 test.f90: In function test: test.f90:1: internal compiler error: in affine_function_equal_p, at tree-data-ref.c:2072 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE with -O2 -ftree-vectorize (regression) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31383
[Bug fortran/33568] New: ICE with ANINT (with KIND and an array)
The following test fails:
$ cat test.f90
PROGRAM Test
IMPLICIT NONE
INTEGER, PARAMETER :: DP=8
REAL(KIND=DP), DIMENSION(1:3) :: A
A = ANINT ( A , DP )
END PROGRAM Test
$ gfortran -c test.f90
test.f90: In function 'MAIN__':
test.f90:1: internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:4052
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20070926
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release
--with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20070926 (experimental) [trunk revision 128777] (GCC)
It compiles fine if A is a scalar (not an array) or if I don't specify
the "kind" in the ANINT function. AINT fails as well, not so NINT,
FLOOR or CEILING.
--
Summary: ICE with ANINT (with KIND and an array)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellby at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33568
[Bug fortran/35108] New: ICE in extract_omp_for_data
With gcc version 4.3.0 20071218, with this file: $ cat test.f90 PROGRAM Outer IMPLICIT NONE REAL, DIMENSION(100) :: A INTEGER :: k !$OMP PARALLEL DO PRIVATE(k) DO k=1,SIZE(A) END DO !$OMP END PARALLEL DO CONTAINS SUBROUTINE Inner IMPLICIT NONE A(k)=0.0D0 END SUBROUTINE Inner END PROGRAM Outer I get this error: $ gfortran -fopenmp test.f90 test.f90: In function outer: test.f90:6: internal compiler error: in extract_omp_for_data, at omp-low.c:163 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Apparently, this happens because the Inner subroutine uses k, which is the loop variable in the parallelized loop, but note that Inner is not even called. -- Summary: ICE in extract_omp_for_data Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35108
[Bug fortran/94270] New: Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 Bug ID: 94270 Summary: Bogus unused dummy argument warning/error Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- Apparently, passing an external procedure as an argument inside an internal procedure triggers it: $ cat test.f90 subroutine foo() external bar call meh(bar) call foo_internal() contains subroutine foo_internal() call meh(bar) end subroutine foo_internal end subroutine foo $ gfortran -c test.f90 -Wall test.f90:7:17: call meh(bar) 1 Warning: Unused dummy argument ‘_formal_0’ at (1) [-Wunused-dummy-argument] $ gfortran --version GNU Fortran (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 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/94270] [8/9 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 --- Comment #6 from Ignacio Fernández Galván --- Will the fix be backported to gcc7? I noticed this when Ubuntu updated the gcc7 version, so I would like to have the chance of seeing it fixed eventually too.
[Bug fortran/96047] New: Bogus unitialized warning for derived type with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96047 Bug ID: 96047 Summary: Bogus unitialized warning for derived type with allocatable components Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- The program below gives a bogus warning when compiling with -O0, but not with -O1 or higher: $ gfortran a.f90 -Wall -O0 a.f90:9:0: call new(a,3) Warning: ‘a.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized] a.f90:9:0: Warning: ‘a.dim[0].lbound’ may be used uninitialized in this function [-Wmaybe-uninitialized] The warning goes away if the "allocate(a(0))" line is uncommented, but that should not be necessary, because the argument is "intent(out)", so it it must be allocated in the subroutine. $ cat a.f90 program test implicit none type foo real, allocatable :: c(:) end type foo type(foo), allocatable :: a(:) !allocate(a(0)) call new(a,3) contains subroutine new(m,n) type(foo), allocatable, intent(out) :: m(:) integer, intent(in) :: n integer :: i allocate(m(n)) do i=1,n allocate(m(i)%c(n)) end do end subroutine new end program
[Bug fortran/92318] New: Nondeterministic ICE with -mcmodel=large -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92318 Bug ID: 92318 Summary: Nondeterministic ICE with -mcmodel=large -O2 Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- Compiling this Fortran code with -mcmodel=large -O2 segfaults intermittently: subroutine diffeq (nvar,y,x1,x2,eps,h1,gvalue) implicit none real*8, parameter :: tiny=1.0d-30 integer i,nvar,nstep,maxstep real*8 x,x1,x2,h,h1,eps,hnext,hdid,y(*) real*8, allocatable :: dydx(:),yscal(:) logical terminate external gvalue terminate = .false. h = sign(h1,x2-x1) nstep = 0 maxstep = 100 allocate (dydx(nvar)) allocate (yscal(nvar)) do while (.not. terminate) do i = 1, nvar yscal(i) = abs(y(i)) + abs(h*dydx(i)) + tiny end do call bsstep (nvar,x,dydx,y,h,eps,yscal,hdid,hnext,gvalue) h = hnext nstep = nstep + 1 if (nstep .ge. maxstep) then terminate = .true. end if end do deallocate (dydx) deallocate (yscal) end $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 diffeq.f:29:0: end internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 $ /usr/bin/gfortran -c -mcmodel=large diffeq.f -o diffeq.o -O2 $ /usr/bin/gfortran --version GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Copyright (C) 2017 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/92613] New: Bogus warning with -cpp and -fpreprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92613 Bug ID: 92613 Summary: Bogus warning with -cpp and -fpreprocessed Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- $ cat a.f90 program test implicit none write(6,*) 'hello' ! it's good! end program $ gfortran -cpp a.f90 -E -o a.pp.f90 && gfortran -cpp -fpreprocessed a.pp.f90 a.f90:4:5: ! it's good! 1 Warning: missing terminating ' character I guess it doesn't make much sense to use -cpp and -fpreprocessed, but it may happen when using some tools (see https://gitlab.kitware.com/cmake/cmake/issues/17466). And, in any case, the warning is "wrong" since the quote is part of a comment line...
[Bug fortran/91442] New: Wrong "may be used uninitialized" warning with allocation on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91442 Bug ID: 91442 Summary: Wrong "may be used uninitialized" warning with allocation on assignment Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- Simple test case: !=== program test character(len=:), allocatable :: string string='Hello world!' write(6,*) string end program !=== Compile with "-Wall": test.f90:3:0: string='' Warning: ‘.string’ may be used uninitialized in this function [-Wmaybe-uninitialized] Adding "-O1" removes the warning, though.
[Bug fortran/90112] New: internal procedure using module procedure instead of "sibling" internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90112 Bug ID: 90112 Summary: internal procedure using module procedure instead of "sibling" internal procedure Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- In some cases an internal procedure will use a module procedure instead of another internal procedure (in the same host unit) with the same name. In the example below, R(x) calls f(x), but it uses the module's f(x) instead of the one internal to g(x) (as probably intended). module test_functions contains subroutine f(x) implicit none real, intent(inout) :: x x = 2 * x end subroutine f subroutine g(x) implicit none real, intent(inout) :: x call R(x) contains subroutine R(x) implicit none real, intent(inout) :: x call f(x) end subroutine R subroutine f(x) implicit none real, intent(inout) :: x x = 3 * x end subroutine f end subroutine g end module program scope use test_functions real :: x = 3.0, y = 3.0 call f(x) call g(y) write(*, *) x, y end program Compiling and running with gfortran 5.4, 7.4, 8.1, gives: 6. 6. Compiling and running with ifort 18.0 gives: 6.00 9.00 This does not happen if f(x) is a function instead of a subroutine, or if the call to f(x) is made directly in g(x) rather than in R(x).
[Bug fortran/85737] gfortran 8.1.0 false positive with -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85737 Ignacio Fernández Galván changed: What|Removed |Added CC||jellby at yahoo dot com --- Comment #2 from Ignacio Fernández Galván --- I hope "more extensive data flow analysis" could easily include simple conditions involving the array index. (j > 4) is a pretty good indication that j-3 > 1, at least to a human.
[Bug fortran/81344] New: Can't disable -ffpe-trap (or not documented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344 Bug ID: 81344 Summary: Can't disable -ffpe-trap (or not documented) Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- Once I enable a floating point exception trap with "-ffpe-trap=whatever", it doesn't seem to be possible to disable it in the same command line (as it is possible with warnings, for instance. An empty list as in "-ffpe-trap=" is accepted, but it doesn't disable traps. This would be useful when using a tool like CMake, where it is convenient to set a default set of flags, and then override them if desired in specific files, rather.
[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344 --- Comment #3 from Ignacio Fernández Galván --- Do you expect any feedback from me? #1 would of course work, but the point is that I'd like to set '-ffpe-trap=set1,set2' as the default for all files, and then disable set2 only for some files. This would be simpler than setting '-ffpe-trap=set1' for some files and '-ffpe-trap=set1,set2' for the "other" files, since I may not know which are the other files. About #2... yes, "do it yourself" is always an option, but what's the purpose of bug reports and feature requests then?
[Bug tree-optimization/34445] [4.3 Regression] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98
--- Comment #3 from jellby at yahoo dot com 2007-12-14 09:37 --- I don't know if it's the same bug, but the message is the same: $ cat test.f Subroutine FndSph(Alpha,Rad) Dimension Rad(100),RadInp(100) Do I = 1, NSphInp Rad(I) = RadInp(I) Alpha = 1.2 End Do End $ gfortran -c -O3 -march=core2 test.f test.f: In function fndsph: test.f:1: internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ gfortran -v Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fx/gfortran_nightbuild/trunk/configure --prefix=/home/fx/gfortran_nightbuild/irun-20071211 --enable-languages=c,fortran --build=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20071211 (experimental) [trunk revision 130765] (GCC) -- jellby at yahoo dot com changed: What|Removed |Added CC| |jellby at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
[Bug fortran/100183] New: Segmentation fault at runtime when passing an internal procedure as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 Bug ID: 100183 Summary: Segmentation fault at runtime when passing an internal procedure as argument Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- I've only been able to reproduce it with: $ uname -a Darwin minimac.moose.housegordon.com 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 arm64 $ gfortran -version GNU Fortran (Homebrew GCC 10.2.0_4) 10.2.1 20201220 Compiling and running the following code works fine, but with -O1 it gives a segmentation fault. Alternatively, undefining INTERNAL_PROC_ARG works with -O1. $ cat test.F90 #define INTERNAL_PROC_ARG [45/90681] module sorting implicit none private public :: argsort real, pointer :: mod_rV(:) interface logical pure function compare_int_t(a, b) integer, intent(in) :: a, b end function end interface contains logical pure function my_compare_rV(x, y) integer, intent(in) :: x, y my_compare_rV = mod_rV(x) <= mod_rV(y) end function function argsort(V) result(idx) real, target, intent(inout) :: V(:) integer :: idx(lbound(V, 1):ubound(V, 1)), i idx = [(i, i = lbound(V, 1), ubound(V, 1))] # ifdef INTERNAL_PROC_ARG call sort(idx, my_compare) # else mod_rV => V call sort(idx, my_compare_rV) # endif contains logical pure function my_compare(x, y) integer, intent(in) :: x, y my_compare = V(x) <= V(y) end function end function argsort subroutine sort(A, compare) integer, intent(inout) :: A(:) procedure(compare_int_t) :: compare integer :: i, j, t do i = lbound(A, 1), ubound(A, 1) do j = i + 1, ubound(A, 1) if (.not. compare(A(i), A(j))) then t = A(i) A(i) = A(j) A(j) = t end if end do end do end subroutine sort end module sorting program test use sorting, only: argsort implicit none integer :: i integer, parameter :: seed(50) = [(i, i = 1, size(seed))] real :: lambdas(5) integer :: idx(size(lambdas)) call random_seed(put=seed) call random_number(lambdas) write(6,*) 'Before sorting:' write(6,*) lambdas(:) idx(:) = argsort(lambdas) write(6,*) 'Argsort:' write(6,*) idx(:) write(6,*) 'Sorted:' write(6,*) lambdas(idx(:)) end program test $ gfortran -O1 test.F90 -o test ; ./test Before sorting: 0.471070886 0.117344737 0.357547939 0.318134785 0.696753800 zsh: segmentation fault ./test $ gfortran -O0 test.F90 -o test ; ./test Before sorting: 0.471070886 0.117344737 0.357547939 0.318134785 0.696753800 Argsort: 2 4 3 1 5 Sorted: 0.117344737 0.318134785 0.357547939 0.471070886 0.696753800
[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 --- Comment #3 from Ignacio Fernández Galván --- If it helps, this happens in gcc304 from https://cfarm.tetaneutral.net/machines/list/, but not in gcc80
[Bug fortran/98787] New: Aliasing not detected with array elements or some intents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98787 Bug ID: 98787 Summary: Aliasing not detected with array elements or some intents Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- With -Waliasing (or -Wall), passing the same array as two dummy arguments with "intent(in)" and "intent(out)" is detected and warned about, but not when only an array element (which may be the whole array with assumed size) is passed, or when "intent(inout)" is used. !== program main implicit none real :: x(100) integer :: i do i=1,size(x) x(i) = i end do ! no warning for this: call sub(size(x),x(1),x(1)) ! warning for this: call sub(size(x),x,x) contains subroutine sub(n,a,b) implicit none integer, intent(in) :: n ! no warning if one of these is inout: real, intent(in) :: a(n) real, intent(out) :: b(n) b(:) = a(:) end subroutine sub end program main !==
[Bug fortran/98883] New: Module variable not initialized with -finit-real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98883 Bug ID: 98883 Summary: Module variable not initialized with -finit-real Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- I use -finit-real=nan hoping to catch some uninitialized variables, but apparently variables in a module are not obeying this flag and are initialized to something else (zero?): != module foo implicit none real :: bar end module foo program test use foo implicit none real :: w write(6,*) w w = bar write(6,*) w end program test != $ gfortran -finit-real=nan a.f90 && ./a.out NaN 0. So, the first printout shows the unitialized w, correctly set to NaN. The second printout should be the variable in the module, which is zero for some reason.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 Ignacio Fernández Galván changed: What|Removed |Added CC||jellby at yahoo dot com --- Comment #2 from Ignacio Fernández Galván --- May I add that it's probably similarly pointless to issue this warning for large arrays in a module (as module variables, not in a procedure)?
[Bug fortran/101827] New: Wrong stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101827
Bug ID: 101827
Summary: Wrong stringop-overflow warning
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jellby at yahoo dot com
Target Milestone: ---
When trying to compile OpenMolcas with gcc 10.1 and link-time optimization I
get:
../src/slapaf_util/outofplane_list.f: In function ‘outofplane_list’:
../src/slapaf_util/outofplane_list.f:524: error: writing 1 byte into a region
of size 0 [-Werror=stringop-overflow=]
524 | Lbls(3)(iE3+1:iE3+1)='('
|
../src/slapaf_util/outofplane_list.f:45:32: note: at offset 0 to object ‘lbls’
with size 40 declared here
45 | Character*(LENIN4) Lbls(4)
|^
[...]
lto1: all warnings being treated as errors
lto-wrapper: fatal error: /usr/bin/gfortran returned 1 exit status
How is "Lbls(3)(iE3+1:iE3+1)" a region of size 0? Similar constructs elsewhere
don't raise the flag. Does the compiler believe "iE3+1" is beyond the length of
the string? But then it says nothing without -flto.
[Bug fortran/101827] Wrong stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101827 --- Comment #2 from Ignacio Fernández Galván --- What's a TU? I didn't succeed (but didn't try to hard) in creating a minimal test case. But this reproduces the problem: $ git clone -b ipo https://gitlab.com/Molcas/OpenMolcas.git $ cd OpenMolcas $ git submodule update --init External/lapack # (comment out the line in src/gateway_util/Symmetry_Info.f90 # that refers to this report, i.e. search for 101827. # But note that the "ipo" branch is in development and will change.) $ mkdir build $ cd build $ cmake -D BUILD_SHARED_LIBS=ON -D BIGOT=ON .. $ make [...] [ 65%] Linking Fortran shared library lib/libmolcas.so In function ‘chtab’, inlined from ‘__symmetry_info_MOD_symmetry_info_setup.part.0’ at /OpenMolcas/src/gateway_util/Symmetry_Info.f90:335:0: /OpenMolcas/src/gateway_util/Symmetry_Info.f90:655: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 655 | lIrrep(iIrrep-1)(i1:i1)='u' | /OpenMolcas/src/gateway_util/Symmetry_Info.f90: In function ‘__symmetry_info_MOD_symmetry_info_setup.part.0’: /OpenMolcas/src/gateway_util/Symmetry_Info.f90:17:60: note: at offset 0 to object ‘lirrep’ with size 24 declared here 17 | Public :: nIrrep, iOper, iChTbl, iChCar, Mul, iChBas, lIrrep, lBsFnc, SymLab, iSkip, & |^ In function ‘chtab’, inlined from ‘__symmetry_info_MOD_symmetry_info_setup.part.0’ at /OpenMolcas/src/gateway_util/Symmetry_Info.f90:335:0: /OpenMolcas/src/gateway_util/Symmetry_Info.f90:653: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 653 |lIrrep(iIrrep-1)(i1:i1)='g' | /OpenMolcas/src/gateway_util/Symmetry_Info.f90: In function ‘__symmetry_info_MOD_symmetry_info_setup.part.0’: /OpenMolcas/src/gateway_util/Symmetry_Info.f90:17:60: note: at offset 0 to object ‘lirrep’ with size 24 declared here 17 | Public :: nIrrep, iOper, iChTbl, iChCar, Mul, iChBas, lIrrep, lBsFnc, SymLab, iSkip, & |^ lto1: all warnings being treated as errors lto-wrapper: fatal error: /usr/bin/gfortran returned 1 exit status
[Bug fortran/101841] New: Wrong realloc-lhs warning with matmul and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101841 Bug ID: 101841 Summary: Wrong realloc-lhs warning with matmul and -O2 Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- I get a warning with this: program test real, allocatable :: F(:,:), A(:,:), B(:,:) allocate(F(10,10), A(10,10), B(10,10)) F(:,:) = 1.0 A(:,:) = 0.5 B(:,:) = 2.0 F(:,:) = F-matmul(a,b) end program test $ gfortran test.f90 -Wrealloc-lhs -O2 No warning with "F(:,:) = matmul(a,b)" Maybe the warning means that a temporary array is created (although I guess it wouldn't be needed)? But as far as I can see there should be no reallocation here.
