<div dir="ltr"><div style="font-size:12.8000001907349px">Hi all,</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">I hope someone could shed some light on the following.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Some basic_string methods have "<span style="color:rgb(0,0,0);font-size:12.8000001907349px">_LIBCPP_INLINE_</span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">VISIBILITY"</span><span style="font-size:12.8000001907349px"> in the <string> header, while others are not. </span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">Where can I look up the rules for which should be inline and which should not?</span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0);font-size:12.8000001907349px">Perhaps that is not the right question to ask, but it is related to a problem I'm seeing in LTO linking with LLVM/Clang/libc++ 3.5 vs 3.6. The string headers have not changed much so I'm thinking the relevant change is in LLVM or Clang.</span></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">For PNaCl, we do linking in this manner:</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Step (1) LTO link of bitcode using gold, and the gold plugin.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">gold -plugin LLVMgold.so <span style="color:rgb(0,0,0)">-plugin-opt=emit-llvm </span>-o merged.bc bc.o bc2.o ... -lapp_native1.a -lapp_native2.a ...  -lc++ -lm ...</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">For various reasons, the setup is such that bc{1,2,...}.o are bitcode, libc++ and libm are bitcode, and the libapp_native{1,2,...}.a are x86.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Step (2) compile the merged.bc to x86 (as merged.o).</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Step (3) link native code: gold -o a.out merged.o -lapp_native1.a -lapp_native2.a ...</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Note that there is no native version of libc++ and libm, so they are absent in this step.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">In LLVM 3.5, step (1) would produce a merged.bc where "<span style="color:rgb(0,0,0)">_ZNSt3__1plIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_12basic_stringIT_T0_T1_EEPKS6_RKS9_" (an operator+ variant) is defined, but in 3.6 it is just a declaration.</span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)">If I use the linker "-y </span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">_ZNSt3...</span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">" option in step (1), it explains that there are a few references to operator+ from within libc++, but no references from any of the bc.o, bc2.o. It is not defined in any of the bc.o, bc2.o either, but it is defined in libapp_native1.a and libc++. This is the same in 3.5 and 3.6.</span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)">Since the </span><span style="color:rgb(0,0,0)">operator+ variant is not in merged.bc w/ 3.6, step (3) ends up pulling the definition from a libapp_native1.a member. However, that member depends on libm for log/exp. For some reason, step (1) does not pull log/exp into merged.bc from the bitcode libm. </span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">So in the end, linking in step (3) fails with undefined references to log/exp. In 3.5, step 3 never needed to pull in that member of </span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">libapp_native1.a.</span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)">If </span><span style="color:rgb(0,0,0)">the operator+ variant was marked inline, then it would end up in merged.bc and there is no need to worry about log/exp either. </span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">That is why I ask about the "inline" rules.</span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)">Otherwise, I'm wondering if it is a bug that, for reasons besides inline, step (1) did not end up with the operator+ definition in merged.bc. </span><span style="font-size:12.8000001907349px;color:rgb(0,0,0)">Or, is entirely reasonable for merged.bc to not have the definition of operator+ (deferring to libapp_native1), and the bug is that merged.bc doesn't end up with the definition of log/exp? <speculation> Maybe a problem is that the member thought to have supplied operator+ from </span><span style="font-size:12.8000001907349px;color:rgb(0,0,0)">libapp_native1.a in step (1) is one that doesn't depend on log/exp, but the one ultimately chosen in step (3) is one that does depend on log/exp </speculation>.</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px;color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px;color:rgb(0,0,0)">Or, is this whole setup of (1), (2), (3) unusual and not expected to work well?</span></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)">Thanks in advance,</span></div><div style="font-size:12.8000001907349px"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8000001907349px">- Jan</div></div>