<div dir="ltr">As you discovered, any translation units which define vtables and do not contain external symbol definitions may be compiled without a summary and with full LTO even if -flto=thin is supplied.<div><br></div><div><div>I was unable to reproduce the comdat group issue you mentioned on the bug with a ToT clang.</div><div><br></div><div><div>$ cat /tmp/guard.cpp </div><div>struct S {</div><div>  struct G { ~G(); int i; };</div><div>  S() {</div><div>    static G i;</div><div>    ii = ++i.i;</div><div>  }</div><div>  int ii;</div><div>};</div><div><br></div><div>S thevar;</div></div><div><div><div>$ clang++ -c -o /tmp/guard.o /tmp/guard.cpp </div></div><div>$ readelf -a /tmp/guard.o</div><div>[...]</div><div><div>COMDAT group section [    5] `.group' [_ZN1SC2Ev] contains 2 sections:</div><div>   [Index]    Name</div><div>   [    6]   .text._ZN1SC2Ev</div><div>   [    7]   .rela.text._ZN1SC2Ev</div><div><br></div><div>COMDAT group section [    9] `.group' [_ZZN1SC1EvE1i] contains 1 sections:</div><div>   [Index]    Name</div><div>   [   10]   .bss._ZZN1SC1EvE1i</div><div><br></div><div>COMDAT group section [   11] `.group' [_ZGVZN1SC1EvE1i] contains 1 sections:</div><div>   [Index]    Name</div><div>   [   12]   .bss._ZGVZN1SC1EvE1i</div></div><div>[...]</div><div><br></div><div>Maybe this somehow only happens with LTO, but I'd check to see if you can reproduce it with regular objects first.</div><div><br></div><div>Peter</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 10:58 AM, Teresa Johnson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+pcc who may have some thoughts<div><br></div><div>But yes, it is legal to mix -flto and -flto=thin - at link time we'll do regularLTO across all the -flto objects and thinLTO on the -flto=thin objects, and the resulting native objects all get linked in the end.</div><div><br></div><div>But if you do -flto=thin we should get a summary block (it will be empty if there are no global values, but we should still do ThinLTO compilation on it). There was a time in the past when we would not generate a summary block when we had inline assembly, as a workaround for some other issues, but that has been fixed. If you are seeing no summary block generated with -flto=thin, can you send me a reproducer? Especially if it reproduces at head.</div><div><br></div><div>Are the issues reported in the bug related to objects that are being handled by regularLTO?</div><div><br></div><div>Teresa</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 10:42 AM, David Callahan <span dir="ltr"><<a href="mailto:dcallahan@fb.com" target="_blank">dcallahan@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>

<div id="m_-6483974772369833517m_-6695570149846914214divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr">
<p>I have now observed that some of the object files, while compiled -flto=thin and determined to be missing the ThinLTOSummary and are being lumped into the "regularLTO" pass. This might explain some of my problem.   Under what conditions would this summary
 be missing? Is it ever legal to mix -flto and -flto=thin object files?</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-6483974772369833517m_-6695570149846914214divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>><br>
<b>Sent:</b> Tuesday, May 16, 2017 9:52:47 AM<br>
<b>To:</b> David Blaikie<br>
<b>Cc:</b> David Callahan; LLVM Dev Mailing list<br>
<b>Subject:</b> Re: [llvm-dev] ThinLTO with Linux+ELF+Gold -- incorrectly dropping weak definitions.</font>
<div> </div>
</div><div><div class="m_-6483974772369833517h5">
<div>
<div dir="ltr">This looks similar to the problem I fixed awhile back in r<span style="font-size:12.8px">292408. I'll take a look (probably tomorrow since I am taking some vacation today).</span>
<div><span style="font-size:12.8px">Teresa</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 16, 2017 at 9:43 AM, David Blaikie <span dir="ltr">
<<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">+Teresa <br>
<br>
<div class="gmail_quote">
<div>
<div class="m_-6483974772369833517m_-6695570149846914214h5">
<div dir="ltr">On Mon, May 15, 2017 at 9:20 AM David Callahan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="m_-6483974772369833517m_-6695570149846914214h5">
<div bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-6483974772369833517m_-6695570149846914214m_4994111992830729365m_3093691112651584606WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">I am tracking a problem with ThinLTO on Linux using gold and elf files where there is a disconnect between gold’s treatment of comdat groups and ThinLTO’s decisions about which weak references to convert to
 available externally.  The net result is a definition is lost and a relocation entry is not handled.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">My status is summarized: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D32980&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiPUrFdOHdaobP7i4hoA&m=DPiCkl9b6jP9-AMbNn0dugb9gFBlyNOKzRq3medq--c&s=DrEkmqUOt4bTaMEhOHPJpR7t5uuU7ux0362_rqDXoT4&e=" target="_blank">
https://bugs.llvm.org/show_bug<wbr>.cgi?id=32980</a> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Anyone familiar with this space and have guidance? Either on how to avoid the problem, or a patch to correct it?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--david<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiPUrFdOHdaobP7i4hoA&m=DPiCkl9b6jP9-AMbNn0dugb9gFBlyNOKzRq3medq--c&s=jrvmGThXXfA5_gGaW24C9hKIgZx6bOjrBEVc_LHKMZQ&e=" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_-6483974772369833517m_-6695570149846914214gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">
Teresa Johnson |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px">
 Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px">
 <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px">
 <a href="tel:(408)%20460-2413" value="+14084602413" target="_blank">408-460-2413</a></td>
</tr>
</tbody>
</table>
</span></div>
</div>
</div>
</div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-6483974772369833517gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:(408)%20460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>