search for: satifisfi

Hello Teresa, > Without -flto, a.o ends up with a reference to __exp_finite, That’s correct. > which also would not be satifisfied out of libexp.a. That’s not correct. Even if libexp.a would have __exp_finite, it wouldn’t be resolved from libexp.a, because of the behavior described in my first message. > Do you also have an implementation of __exp_finite in your libexp.a? No, I don’t have __exp_finite in libexp.a. I pres...

A couple questions/notes so I can understand better: Without -flto, a.o ends up with a reference to __exp_finite, which also would not be satifisfied out of libexp.a. Do you also have an implementation of __exp_finite in your libexp.a? Can you build with -fno-builtin, or -fno-builtin-exp etc? That results in a reference to __exp_finite in the .o bitcode (which of course has the same issue I mentioned above, but is consistent). That seems to b...

Dear community, Recently I discovered that llvm gold linker plugin (LLVMgold.so) doesn't add llvm instrinsics symbols to the linker symbol table. I do not claim that something is necessary wrong, just want to share my observations with the community. Brief summary If I create a static library with a custom version of 'exp()' math function and link it as follows: $

+pcc for thoughts On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <denis.bakhvalov at intel.com > wrote: > Hello Teresa, > > > > > Without -flto, a.o ends up with a reference to __exp_finite, > > That’s correct. > > > > > which also would not be satifisfied out of libexp.a. > > That’s not correct. Even if libexp.a would have __exp_finite, it wouldn’t > be resolved from libexp.a, because of the behavior described in my first > message. > I'm asking specifically about the non-LTO case. > > > > Do you also have an imple...