I get an "undefined reference" error when linking two files but that variable is static. This only happens with gcc 4.2, and only when I enable both -g and -O1 (or higher). (sid)473:tbm@reyes: ~] cat test.c static const char utf8_skip_data[1] = {1}; static const char * const gconf_g_utf8_skip = utf8_skip_data; (sid)474:tbm@reyes: ~] cat main.c int main() { } (sid)475:tbm@reyes: ~] gcc -c -o main.o main.c (sid)476:tbm@reyes: ~] gcc -c -g -O2 -o test.o test.c (sid)477:tbm@reyes: ~] gcc main.o test.o test.o:(.debug_info+0x93): undefined reference to `utf8_skip_data' collect2: ld returned 1 exit status zsh: exit 1 gcc main.o test.o (sid)478:tbm@reyes: ~] gcc-4.1 -c -g -O2 -o test.o test.c (sid)479:tbm@reyes: ~] gcc main.o test.o (sid)480:tbm@reyes: ~] gcc -c -g -O0 -o test.o test.c (sid)481:tbm@reyes: ~] gcc main.o test.o (sid)482:tbm@reyes: ~] This is with 4.2.0 20060419. 20060517 shows the same.
Confirmed. The reference is the relocation for DW_AT_const_value. $ readelf -wi test.o [snip] <1><7a>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0x0): gconf_g_utf8_skip DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type : <89> DW_AT_const_value : 0 [snip] $ readelf -r test.o Relocation section '.rela.debug_info' at offset 0x53c contains 8 entries: [snip] 00000085 00000b01 R_PPC_ADDR32 00000000 utf8_skip_data + 0
*** Bug 27950 has been marked as a duplicate of this bug. ***
Created attachment 12037 [details] patch It looks like we should bite the bullet and let cgraph code to output the debug info.... I am testing the attached patch Honza
*** Bug 28673 has been marked as a duplicate of this bug. ***
Janis, Can you do a regression hunt on this bug? I almost think it was caused by revision 112408.
A regression hunt on powerpc-linux identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=112361 r112361 | geoffk | 2006-03-24 21:59:48 +0000 (Fri, 24 Mar 2006) The log message and the ChangeLog entry don't mention it, but this patch also modifies gcc/dwarf2out.c.
(In reply to comment #6) > The log message and the ChangeLog entry don't mention it, but this patch also > modifies gcc/dwarf2out.c. It was backed out right after the commit: http://gcc.gnu.org/viewcvs?view=rev&revision=112362 But that would mean it was caused by the revision which I had mentioned in comment #5 as that revision put the code back in.
(In reply to comment #3) > Created an attachment (id=12037) [edit] > patch > > It looks like we should bite the bullet and let cgraph code to output the debug > info.... I am testing the attached patch > It looks like this patch will prevent the output of debug information for variables that are optimized out, but that's wrong; the variables should be visible to the user in the debugger even if they are optimized away. I think the actual problem is that reference_to_unused in dwarf2out.c is checking TREE_USED and expecting all used variables to be output, but that doesn't seem to be happening in this case. Perhaps there is something in cgraph which can be called to ask if a variable is *really* going to be output?
I can confirm that the latest regression is from r112408.
*** Bug 29417 has been marked as a duplicate of this bug. ***
Btw, the following C++ example fails to link even without -O: ============================= const char s[] = ""; const char *const p = s; int main() { return 0; } =============================
*** Bug 30305 has been marked as a duplicate of this bug. ***
I'm testing Index: dwarf2out.c =================================================================== --- dwarf2out.c (revision 121287) +++ dwarf2out.c (working copy) @@ -10045,8 +10045,14 @@ reference_to_unused (tree * tp, int * wa if (DECL_P (*tp) && ! TREE_PUBLIC (*tp) && ! TREE_USED (*tp) && ! TREE_ASM_WRITTEN (*tp)) return *tp; - else - return NULL_TREE; + else if (DECL_P (*tp)) + { + struct varpool_node *node = varpool_node (*tp); + if (!node->needed) + return *tp; + } + + return NULL_TREE; } /* Generate an RTL constant from a decl initializer INIT with decl type TYPE,
*** Bug 30629 has been marked as a duplicate of this bug. ***
Subject: Bug 27657 Author: rguenth Date: Tue Jan 30 10:23:01 2007 New Revision: 121335 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121335 Log: 2007-01-30 Richard Guenther <rguenther@suse.de> PR middle-end/27657 * dwarf2out.c (reference_to_unused): Query varpool if the variable was output. * g++.dg/debug/pr27657.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/debug/pr27657.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
Fixed on the mainline.
*** Bug 30651 has been marked as a duplicate of this bug. ***
Any chance of a 4.2 backport ? Looks like varpool_node does not exist in 4.2 branch.
(In reply to comment #18) > Any chance of a 4.2 backport ? Looks like varpool_node does not exist in 4.2 > branch. I noticed this as well. It's easy enough to fix: 14:20 < richi> tbm: sure s/varpool_/cgraph_varpool_/ Richi has already tested the patch on 4.2 so I assume he'll apply it soon.
(In reply to comment #19) > (In reply to comment #18) > > Any chance of a 4.2 backport ? Looks like varpool_node does not exist in 4.2 > > branch. > > I noticed this as well. It's easy enough to fix: > > 14:20 < richi> tbm: sure s/varpool_/cgraph_varpool_/ > > Richi has already tested the patch on 4.2 so I assume he'll apply it soon. Nice, thanks :)
Subject: Bug 27657 Author: rguenth Date: Sun Feb 4 15:27:53 2007 New Revision: 121576 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121576 Log: 2007-02-04 Richard Guenther <rguenther@suse.de> Backport from mainline: 2007-01-30 Richard Guenther <rguenther@suse.de> PR middle-end/27657 * dwarf2out.c (reference_to_unused): Query varpool if the variable was output. * g++.dg/debug/pr27657.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/pr27657.C - copied unchanged from r121335, trunk/gcc/testsuite/g++.dg/debug/pr27657.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/dwarf2out.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Fixed.
(In reply to comment #22) > Fixed. I can confirm this - with the exception of one case for which I filed a new report: PR30700.