[Bug c/51900] New: [4.6 Regression] const variable initialization always zero

[Bug c/51900] New: [4.6 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

             Bug #: 51900
           Summary: [4.6 Regression] const variable initialization always
                    zero
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.f.starke@freenet.de
              Host: mingw32
            Target: mingw32
             Build: mingw32


/* a.c */
#include "a.h"
const int myVar[3] = { 5, 6, 7 };

/* a.h */
#ifndef a_h
#define a_h
const int myVar[3];
#endif

/* main.c */
#include <stdio.h>
#include "a.h"
void main() {
 int i;
 for (i = 0; i < 3; i++) printf("myVar[%i] = %i\n", i, myVar[i]);
 fflush(stdout);
}

Result gcc 4.5.2:
myVar[0] = 5
myVar[1] = 6
myVar[2] = 7

Result gcc 4.6.2:
myVar[0] = 0
myVar[1] = 0
myVar[2] = 0

Configurations:
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw452\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw452/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --disable-nls --disable-shared --enable-static
--enable-libgcj --enable-libgomp --enable-lto --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--program-suffix= --build=mingw32 --enable-abi=32 --enable-checking=release
Thread model: win32
gcc version 4.5.2 (GCC)

Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw462\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw462/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--disable-nls --disable-shared --enable-static --enable-libgcj --enable-libgomp
--enable-lto --with-dwarf2 --disable-win32-registry
--enable-version-specific-runtime-libs --build=mingw32 --enable-abi=32
--enable-checking=release --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)

Compiled with:
CC = gcc
CFLAGS = -static -O2
LDFLAGS = -static

all: main.exe

.PHONY: clean
clean:
    rm -f *.o
    rm -f *.exe

main.exe: main.o a.o
    $(CC) $(LDFLAGS) -o main.exe main.o a.o

main.o: main.c
    $(CC) $(CFLAGS) -o main.o -c main.c

a.o: a.c
    $(CC) $(CFLAGS) -o a.o -c a.c

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-01-19
          Component|c                           |target
   Target Milestone|---                         |4.6.3
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-19 11:19:59 UTC ---
This is a valid optimization if you build with -fno-common.  Please make sure
that -fcommon is in effect.

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2012-01-19 11:34:52 UTC ---
I can reproduce with x86_64-w64-mingw32-gcc-4.6.2 on cygwin.  Adding 'extern'
to the declaration in the .h file fixes it.

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #3 from Daniel Starke <daniel.f.starke at freenet dot de> 2012-01-19 11:52:27 UTC ---
[...]
COLLECT_GCC_OPTIONS='-static' '-O2' '-v' '-Q' '-o' 'a.o' '-c' '-mtune=i386'
'-march=i386'
[...]
GNU C (GCC) version 4.6.2 (mingw32)
        compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 2.4.2,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed:  -v
 -iprefix d:\programme\msys\mingw462\bin\../lib/gcc/mingw32/4.6.2/ a.c
 -mtune=i386 -march=i386 -auxbase-strip a.o -O2
options enabled:  -falign-labels -fasynchronous-unwind-tables
 -fauto-inc-dec -fbranch-count-reg -fcaller-saves
 -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers
 -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks
 -fdevirtualize -fdwarf2-cfi-asm -fearly-inlining
 -feliminate-unused-debug-types -fexpensive-optimizations
 -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 -findirect-inlining -finline -finline-functions-called-once
 -finline-small-functions -fipa-cp -fipa-profile -fipa-pure-const
 -fipa-reference -fipa-sra -fira-share-save-slots -fira-share-spill-slots
 -fivopts -fkeep-inline-dllexport -fkeep-static-consts -fleading-underscore
 -fmath-errno -fmerge-constants -fmerge-debug-strings
 -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
 -foptimize-sibling-calls -fpartial-inlining -fpeephole -fpeephole2
 -fprefetch-loop-arrays -freg-struct-return -fregmove -freorder-blocks
 -freorder-functions -frerun-cse-after-loop -fsched-critical-path-heuristic
 -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
 -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
 -fsched-spec-insn-heuristic -fsched-stalled-insns-dep
 -fset-stack-executable -fshow-column -fsigned-zeros
 -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
 -fstrict-overflow -fstrict-volatile-bitfields -fthread-jumps
 -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce
 -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim
 -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
 -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
 -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre
 -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink
 -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter
 -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables
 -fvar-tracking -fvar-tracking-assignments -fvect-cost-model
 -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double
 -maccumulate-outgoing-args -malign-double -malign-stringops
 -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mno-red-zone -mno-sse4
 -mpush-args -msahf -mstack-arg-probe
[...]

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-19 11:57:18 UTC ---
(In reply to comment #3)
> [...]
> COLLECT_GCC_OPTIONS='-static' '-O2' '-v' '-Q' '-o' 'a.o' '-c' '-mtune=i386'
> '-march=i386'
> [...]
> GNU C (GCC) version 4.6.2 (mingw32)
>         compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 2.4.2,
> MPC version 0.9
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> options passed:  -v
>  -iprefix d:\programme\msys\mingw462\bin\../lib/gcc/mingw32/4.6.2/ a.c
>  -mtune=i386 -march=i386 -auxbase-strip a.o -O2
> options enabled:  -falign-labels -fasynchronous-unwind-tables
>  -fauto-inc-dec -fbranch-count-reg -fcaller-saves
>  -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers
>  -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks
>  -fdevirtualize -fdwarf2-cfi-asm -fearly-inlining
>  -feliminate-unused-debug-types -fexpensive-optimizations
>  -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
>  -fguess-branch-probability -fident -fif-conversion -fif-conversion2
>  -findirect-inlining -finline -finline-functions-called-once
>  -finline-small-functions -fipa-cp -fipa-profile -fipa-pure-const
>  -fipa-reference -fipa-sra -fira-share-save-slots -fira-share-spill-slots
>  -fivopts -fkeep-inline-dllexport -fkeep-static-consts -fleading-underscore
>  -fmath-errno -fmerge-constants -fmerge-debug-strings
>  -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
>  -foptimize-sibling-calls -fpartial-inlining -fpeephole -fpeephole2
>  -fprefetch-loop-arrays -freg-struct-return -fregmove -freorder-blocks
>  -freorder-functions -frerun-cse-after-loop -fsched-critical-path-heuristic
>  -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
>  -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
>  -fsched-spec-insn-heuristic -fsched-stalled-insns-dep
>  -fset-stack-executable -fshow-column -fsigned-zeros
>  -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
>  -fstrict-overflow -fstrict-volatile-bitfields -fthread-jumps
>  -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce
>  -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim
>  -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
>  -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
>  -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre
>  -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink
>  -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter
>  -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables
>  -fvar-tracking -fvar-tracking-assignments -fvect-cost-model
>  -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double
>  -maccumulate-outgoing-args -malign-double -malign-stringops
>  -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mno-red-zone -mno-sse4
>  -mpush-args -msahf -mstack-arg-probe
> [...]

I don't think that proves anything.  Please reproduce with explicit
-fcommon added.

That said, works for me on x86_64-linux.

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #5 from Daniel Starke <daniel.f.starke at freenet dot de> 2012-01-19 14:51:33 UTC ---
Compiling it with
gcc -static -fcommon -o main.o -c main.c
gcc -static -fcommon -o a.o -c a.c
gcc -static -o main.exe main.o a.o
results in
$ ./main
myVar[0] = 5
myVar[1] = 6
myVar[2] = 7

Compiling it with
gcc -static -O2 -fcommon -o main.o -c main.c
gcc -static -O2 -fcommon -o a.o -c a.c
gcc -static -o main.exe main.o a.o
results in
$ ./main
myVar[0] = 0
myVar[1] = 0
myVar[2] = 0

Thus a different option causes this change.

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |ktietz at gcc dot gnu.org

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-19 15:01:28 UTC ---
Ugh.  I think this is a bug in the way i386_pe_binds_local_p implements
the binds_local target macro:

bool
i386_pe_binds_local_p (const_tree exp)
{
  /* PE does not do dynamic binding.  Indeed, the only kind of
     non-local reference comes from a dllimport'd symbol.  */
  if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
      && DECL_DLLIMPORT_P (exp))
    return false;

  /* Or a weak one, now that they are supported.  */
  if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
      && DECL_WEAK (exp))
    return false;

  return true;
}

It's completely bogus to return true at the end - you have to do

  return default_binds_local_p (exp);

to get even slightly correct/optimal handling.  Thus, confirmed as a target
issue.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.6 Regression] const      |[4.6/4.7 Regression] const
                   |variable initialization     |variable initialization
                   |always zero                 |always zero

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-19 15:06:08 UTC ---
Btw, surely latent since forever, thus since the introduction of the override.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #8 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-01-20 01:36:42 UTC ---
As PE-COFF targets don't have GOT tables and ELF-shared object model, it would
be absolute incorrect to return here result of default_binds_local_p (exp)
instead of true. The function 'default_binds_local_p' is ELF-specific and is
not usable for PE-COFF targets at all.
This testcase contains double declaration of myVar.  You can see this by
turning on -Wall option on compile.  The cause is that in the header the
extern-keyword is missing.
This is no gcc bug.  This is a binutils bug, which doesn't see that here are
two equal named symbols defined - one in data and one in comm.

  I noticed that earlier by a different bug, that .comm double definitions in
.comm aren't detected on link-time.  This is a binutils bug.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-20 07:33:36 UTC ---
Dunno about PE-COFF, but at least in ELF merging of .data (or .rodata) and
common symbols works by keeping the non-common symbol and it is the behavior
that GCC expects with -fcommon. If the PE-COFF linker handles it the same, then
if you can't use default_binds_local_p, you should at least copy over the
common symbol handling from it.
int i = 5;
in one file and
int i;
in another one with -fcommon just provides the int i = 5; definition and
int i; in two files provides int i = 0; definition.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #10 from Daniel Starke <daniel.f.starke at freenet dot de> 2012-01-20 07:41:10 UTC ---
I have tested the problem with the option switches -O0, -O1, -O2, -O3, -O4, -Os
and -Ofast. Only -O0 results in a 5, 6, 7 output. Turning on the options listed
in the documentation activated by -O1 and -O2 in any combination (also all
together) does not results in the problematic output of 0, 0, 0. I have also
used -Wall to detect the issue, however the only warning this returns is
main.c:3:6: warning: return type of 'main' is not 'int' [-Wmain]
Compiling the test case with -O1 -flto results in the same faulty output.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #11 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2012-01-20 22:37:02 UTC ---
It looks like a GCC bug, not INVALID.

myVar[i] is replaced by constant zero in main().

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

--- Comment #12 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-01-23 19:55:40 UTC ---
Author: ktietz
Date: Mon Jan 23 19:55:35 2012
New Revision: 183450

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183450
Log:
    PR target/51900
    * config/i386/predicates.md (symbolic_operand): Allow
    UNSPEC_PCREL as PIC expression for lea.
    * config/i386/winnt.c (i386_pe_binds_local_p): Reworked.
    * config/i386/i386.c (ix86_delegitimize_address): Handle
    UNSPEC_PCREL for none-MEM, too.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/predicates.md
    trunk/gcc/config/i386/winnt.c

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #13 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-01-23 20:46:23 UTC ---
This patch is too invasive for back-porting to 4.6.3 IMHO. Especially we would
introduce on 4.6 the display of note-messages about UNSPEC_PCREL in dwarf2out.
On trunk it fixed, so I close it.