Bug 208669

Summary: &&label uses generate references to unknown symbols
Product: [Fedora] Fedora Reporter: Jeremy Fitzhardinge <jeremy>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-16 18:43:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
filemap.i exhibits this problem when compiled with gcc -c -O filemap.i
none
output assembler, showing dangling reference to .L1020 none

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).