Bug 208669 - &&label uses generate references to unknown symbols
Summary: &&label uses generate references to unknown symbols
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-29 23:32 UTC by Jeremy Fitzhardinge
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-16 18:43:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
filemap.i exhibits this problem when compiled with gcc -c -O filemap.i (682.76 KB, text/plain)
2006-09-29 23:32 UTC, Jeremy Fitzhardinge
no flags Details
output assembler, showing dangling reference to .L1020 (123.97 KB, text/plain)
2006-09-29 23:33 UTC, Jeremy Fitzhardinge
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 29484 0 None None None Never

Description Jeremy Fitzhardinge 2006-09-29 23:32:38 UTC
Description of problem:
I'm trying to create instances of a structure into a section; those structures
contain references to &&labels.  For some reason, I'm getting these being
emitted with references to unknown labels.

Version-Release number of selected component (if applicable):
gcc-4.1.1-24

How reproducible:
Always

Steps to Reproduce:
1.compile attached .i file with gcc -c -O filemap.i
2.nm -u filemap.o shows unknown symbol .L1020 (or similar)
3.
  
Actual results:
Undefined local symbol:
$ nm -u filemap.o|grep '\.L'
U .L1020

Expected results:
No undefined local symbols

Additional info:
This is what happens when I use the asm("" : : "m" (foo)) workaround for bug
#208667 (without this workaround, nothing is emitted into the __bug_table
section at all).  I suspect this is something to do with entries being emitted
into __bug_table even though the corresponding code has been optimised out.

Comment 1 Jeremy Fitzhardinge 2006-09-29 23:32:39 UTC
Created attachment 137453 [details]
filemap.i exhibits this problem when compiled with gcc -c -O filemap.i

Comment 2 Jeremy Fitzhardinge 2006-09-29 23:33:58 UTC
Created attachment 137454 [details]
output assembler, showing dangling reference to .L1020

Comment 3 Jakub Jelinek 2006-10-16 15:40:57 UTC
Reproduced on:
static inline __attribute__((always_inline))
void bar (void)
{
  addr:;
  static const unsigned long b __attribute__((__used__))
__attribute__((section("btable")))
    = (unsigned long) &&addr;
  asm ("" : : "m" (b));
}

void foo (void)
{
  bar ();
}
even on GCC trunk, the tree inliner doesn't correctly remap the static variable
when inlining.

Comment 4 Jakub Jelinek 2006-10-16 18:43:37 UTC
Tracking this upstream, but I believe your testcase is invalid and GCC should
issue an error on it (because of always_inline attribute).


Note You need to log in before you can comment on or make changes to this bug.