Bug 66141 - Invalid code generation with -O1, -O2, -O3 for x86_64 target for array reference in Fortran COMMON
Summary: Invalid code generation with -O1, -O2, -O3 for x86_64 target for array refere...
Status: RESOLVED DUPLICATE of bug 53086
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.9.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-14 09:26 UTC by george
Modified: 2015-05-14 10:03 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Self-contained program to show buggy functionality (572 bytes, text/plain)
2015-05-14 09:26 UTC, george
Details

Note You need to log in before you can comment on or make changes to this bug.
Description george 2015-05-14 09:26:35 UTC
Created attachment 35540 [details]
Self-contained program to show buggy functionality

Attached short Fortran program functions properly with no optimization or -O0 but not when -O1, -O2, or -O3 used.  Code generation for references to storage in Fortran COMMON incorrect.

Expected output, when compiled with -O0 or no optimization is:

 kvalue should be OK but is OK

Output when compiled with -O1, -O2, or -O3 is:

 kvalue should be OK but is UNDEFINE

[Program generates warning on compilation, but this is allowed under the semantics of Fortran COMMON (allocated COMMON storage is longest among any of its definition).]
Comment 1 george 2015-05-14 09:36:29 UTC
uname -m -r -s -p output:
Darwin 13.4.0 x86_64 i386
Comment 2 george 2015-05-14 09:41:34 UTC
#gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.9.2/libexec/gcc/x86_64-apple-darwin13.4.0/4.9.2/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../configure --build=x86_64-apple-darwin13.4.0 --prefix=/usr/local/Cellar/gcc/4.9.2 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.9 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog --with-isl=/usr/local/opt/isl --with-system-zlib --enable-version-specific-runtime-libs --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc 4.9.2' --with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin --disable-nls --enable-multilib
Thread model: posix
gcc version 4.9.2 (Homebrew gcc 4.9.2)
Comment 3 Dominique d'Humieres 2015-05-14 10:03:49 UTC
> [Program generates warning on compilation, but this is allowed under
> the semantics of Fortran COMMON (allocated COMMON storage is longest
> among any of its definition).]

Nope! see the second item below:

5.7.2.5 Dierences between named common and blank common

1 A blank common block has the same properties as a named common block,
  except for the following.

 Execution of a RETURN or END statement might cause data objects in a named
 common block to become undefined unless the common block has the SAVE attribute,
 but never causes data objects in blank common to become undefined (16.6.6).

 Named common blocks of the same name shall be of the same size in all scoping
 units of a program in which they appear, but blank common blocks may be of
 different sizes.

 A data object in a named common block may be initially defined by means of
 a DATA statement or type declaration statement in a block data program unit
 (11.3), but objects in blank common shall not be initially defined.

*** This bug has been marked as a duplicate of bug 53086 ***