Bug 208669 - &&label uses generate references to unknown symbols
&&label uses generate references to unknown symbols
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-29 19:32 EDT by Jeremy Fitzhardinge
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-16 14:43:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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 19:32 EDT, Jeremy Fitzhardinge
no flags Details
output assembler, showing dangling reference to .L1020 (123.97 KB, text/plain)
2006-09-29 19:33 EDT, Jeremy Fitzhardinge
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 29484 None None None Never

  None (edit)
Description Jeremy Fitzhardinge 2006-09-29 19:32:38 EDT
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 19:32:39 EDT
Created attachment 137453 [details]
filemap.i exhibits this problem when compiled with gcc -c -O filemap.i
Comment 2 Jeremy Fitzhardinge 2006-09-29 19:33:58 EDT
Created attachment 137454 [details]
output assembler, showing dangling reference to .L1020
Comment 3 Jakub Jelinek 2006-10-16 11:40:57 EDT
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 14:43:37 EDT
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.