This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/69360] New: loop optimization produces invalid code when a common array has dimension 1 in some files
- From: "genericsoma at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 19 Jan 2016 17:05:22 +0000
- Subject: [Bug fortran/69360] New: loop optimization produces invalid code when a common array has dimension 1 in some files
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360
Bug ID: 69360
Summary: loop optimization produces invalid code when a common
array has dimension 1 in some files
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: genericsoma at gmail dot com
Target Milestone: ---
I'm not sure if this bug is a valid one, as it depends on two common blocks
declared with different array size. This happens in out legacy code which had
no such problem in version 4.4.3 of gfortran. The versions which were found to
have problem are 4.8.2 on Linux and 5.2.0 on Windows using MSYS2/MinGW-w64.
Basically, when compiling with -O1 optimization flag, it appears as if the line
"e(kr)=e(kr)+e(k)" is optimized out. -O0 produces expected behaviour.
init.f:
subroutine init
common/e/e(6)
do i=1,6
e(i)=i
end do
end
test.f:
program test
common/e/e(1)
call init
do i=1,3
kr=i*2-1
k=i*2
e(kr)=e(kr)+e(k)
e(k)=1.d0
end do
print *,e(1)
end
Compiled with
gfortran -O1 com.f test.f
outputs
1.00000000,
while compiled with
gfortran -O0 com.f test.f
outputs
3.00000000.
Changing "e(k)=1.d0" to "if (e(k).gt.0.d0) e(k)=1.d0" also eliminates the
problem.