<html>
    <head>
      <base href="https://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - --start-lib/--end-lib sometimes ignored with LTO"
   href="https://llvm.org/bugs/show_bug.cgi?id=26807">26807</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>--start-lib/--end-lib sometimes ignored with LTO
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Linker
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>eugeni.stepanov@gmail.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>This is similar to PR26674, but the problem happens in a different place and
the proposed fix for PR26674 does not affect this. I'm almost sure the bug is
actually in gold, but I can only reproduce it with the LLVM plugin at this
point, so I'm filing the C++-level test case here.


$ cat 1.h
struct A {
  A(void *);
};

$ cat 1.cc
#include <stdio.h>
#include "1.h"
A::A(void *p) { printf("register %p\n", p); }

$ cat 2.cc
#include "1.h"
bool q;
static A a(&q);
int main() {}

$ cat 3.cc
#include "1.h"
bool z;
static A a(&z);

$ ./bin/clang++ 1.cc 2.cc 3.cc -flto -c
$ ./bin/clang++ -flto -fuse-ld=gold 2.o -Wl,--start-lib 3.o -Wl,--end-lib
-Wl,--start-lib 3.o -Wl,--end-lib 1.o

/usr/bin/ld.gold: error: 3.o: multiple definition of 'z'
/usr/bin/ld.gold: 3.o: previous definition here

Basically, gold decided to link 3.o even though it does not resolve any new
symbols.

If the second instance of 3.o is removed from the link line, then the link
succeeds, but the resulting executable incorrectly runs the A::A(&z)
initializer (which proves that 3.o was included in the link).

This is the list of symbols that the plugin returns to gold for 3.o, both with
default visibility:
  UNDEF  _ZN1AC1EPv
  DEF    z</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>