* [Bug target/51900] [4.6 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
@ 2012-01-19 11:29 ` rguenth at gcc dot gnu.org
2012-01-19 12:01 ` mikpe at it dot uu.se
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-19 11:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
2012-01-19 11:29 ` [Bug target/51900] " rguenth at gcc dot gnu.org
@ 2012-01-19 12:01 ` mikpe at it dot uu.se
2012-01-19 12:18 ` daniel.f.starke at freenet dot de
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: mikpe at it dot uu.se @ 2012-01-19 12:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
2012-01-19 11:29 ` [Bug target/51900] " rguenth at gcc dot gnu.org
2012-01-19 12:01 ` mikpe at it dot uu.se
@ 2012-01-19 12:18 ` daniel.f.starke at freenet dot de
2012-01-19 12:21 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: daniel.f.starke at freenet dot de @ 2012-01-19 12:18 UTC (permalink / raw)
To: gcc-bugs
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
[...]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (2 preceding siblings ...)
2012-01-19 12:18 ` daniel.f.starke at freenet dot de
@ 2012-01-19 12:21 ` rguenth at gcc dot gnu.org
2012-01-19 15:03 ` daniel.f.starke at freenet dot de
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-19 12:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (3 preceding siblings ...)
2012-01-19 12:21 ` rguenth at gcc dot gnu.org
@ 2012-01-19 15:03 ` daniel.f.starke at freenet dot de
2012-01-19 15:04 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: daniel.f.starke at freenet dot de @ 2012-01-19 15:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (4 preceding siblings ...)
2012-01-19 15:03 ` daniel.f.starke at freenet dot de
@ 2012-01-19 15:04 ` rguenth at gcc dot gnu.org
2012-01-19 15:16 ` [Bug target/51900] [4.6/4.7 " rguenth at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-19 15:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (5 preceding siblings ...)
2012-01-19 15:04 ` rguenth at gcc dot gnu.org
@ 2012-01-19 15:16 ` rguenth at gcc dot gnu.org
2012-01-20 2:50 ` ktietz at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-19 15:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (6 preceding siblings ...)
2012-01-19 15:16 ` [Bug target/51900] [4.6/4.7 " rguenth at gcc dot gnu.org
@ 2012-01-20 2:50 ` ktietz at gcc dot gnu.org
2012-01-20 7:52 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-01-20 2:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (7 preceding siblings ...)
2012-01-20 2:50 ` ktietz at gcc dot gnu.org
@ 2012-01-20 7:52 ` jakub at gcc dot gnu.org
2012-01-20 7:54 ` daniel.f.starke at freenet dot de
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-01-20 7:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (8 preceding siblings ...)
2012-01-20 7:52 ` jakub at gcc dot gnu.org
@ 2012-01-20 7:54 ` daniel.f.starke at freenet dot de
2012-01-21 0:00 ` d.g.gorbachev at gmail dot com
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: daniel.f.starke at freenet dot de @ 2012-01-20 7:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (9 preceding siblings ...)
2012-01-20 7:54 ` daniel.f.starke at freenet dot de
@ 2012-01-21 0:00 ` d.g.gorbachev at gmail dot com
2012-01-23 20:38 ` ktietz at gcc dot gnu.org
2012-01-23 21:17 ` ktietz at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: d.g.gorbachev at gmail dot com @ 2012-01-21 0:00 UTC (permalink / raw)
To: gcc-bugs
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().
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (10 preceding siblings ...)
2012-01-21 0:00 ` d.g.gorbachev at gmail dot com
@ 2012-01-23 20:38 ` ktietz at gcc dot gnu.org
2012-01-23 21:17 ` ktietz at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-01-23 20:38 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero
2012-01-19 10:48 [Bug c/51900] New: [4.6 Regression] const variable initialization always zero daniel.f.starke at freenet dot de
` (11 preceding siblings ...)
2012-01-23 20:38 ` ktietz at gcc dot gnu.org
@ 2012-01-23 21:17 ` ktietz at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-01-23 21:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread