search for: nainar

LLD revision is r331862. To add, I had initially tried it on r328903, which also reproduced the issue. On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > Hi Teresa, > > Thanks for looking into this. I hadn't initially tried ToT, but it > reproduces in ToT as well when I tried. > > $ ./clang --version > > clang version 7.0.0 (trunk 331879) (llvm/trunk 331888) > Target: x86_64-unkn...

Sorry, operator error. I can reproduce now. Interestingly, this does not reproduce using gold, and they utilize the same underlying LTO API. Let me dig a little using save-temps and see where they diverge. Teresa On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > LLD revision is r331862. To add, I had initially tried it on r328903, > which also reproduced the issue. > > On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> > wrote: > >> Hi Teresa, >> >> T...

...t; wrote: > Sorry, operator error. I can reproduce now. Interestingly, this does not > reproduce using gold, and they utilize the same underlying LTO API. Let me > dig a little using save-temps and see where they diverge. > Teresa > > On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> > wrote: > >> LLD revision is r331862. To add, I had initially tried it on r328903, >> which also reproduced the issue. >> >> On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> >> wrote: >> >&g...

...can reproduce now. Interestingly, this does not >>> reproduce using gold, and they utilize the same underlying LTO API. Let me >>> dig a little using save-temps and see where they diverge. >>> Teresa >>> >>> On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> >>> wrote: >>> >>>> LLD revision is r331862. To add, I had initially tried it on r328903, >>>> which also reproduced the issue. >>>> >>>> On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama a...

...y, operator error. I can reproduce now. Interestingly, this does not >> reproduce using gold, and they utilize the same underlying LTO API. Let me >> dig a little using save-temps and see where they diverge. >> Teresa >> >> On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> >> wrote: >> >>> LLD revision is r331862. To add, I had initially tried it on r328903, >>> which also reproduced the issue. >>> >>> On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> >&gt...

...esa Johnson <tejohnson at google.com> wrote: > Hi Pirama, > > I can't reproduce with either lld or gold, using a compiler built from > head. What version is your clang? > (and your lld) > > Thanks, > Teresa > > On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. >> IIUC, these are supposed to be weak symbols but Thin LTO seems to break >> this in some way. This does't happen...

...gt;> Hi Pirama, >> >> I can't reproduce with either lld or gold, using a compiler built from >> head. What version is your clang? >> > (and your lld) > > >> >> Thanks, >> Teresa >> >> On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. >>> IIUC, these are supposed to be weak symbols but Thin LTO seems to break >>> this in some way. Thi...

The gold plugin supports many of the backend options. But Clang doesn't pass all of them to the plugin as it does to the backend. For example, to support -emulated-tls with LTO, Clang needs to pass -emulated-tls to the LTO backend. Shall I just change the driver to add -plugin-opt=-emulated-tls or is the best practice to embed this in the IR? -------------- next part -------------- An HTML

Hi Pirama, I can't reproduce with either lld or gold, using a compiler built from head. What version is your clang? Thanks, Teresa On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. > IIUC, these are supposed to be weak symbols but Thin LTO seems to break > this in some way. This does't happen with gold or no LTO o...

...It's not a small patch here or there, it > requires more research. We should discuss it in full. > > I support recovering from invalid COFF files to avoid crashes in any way > we can, though, so this patch might still be good. > > On Thu, Jun 7, 2018 at 2:44 PM Pirama Arumuga Nainar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I encountered a segfault when using lld to cross-compile for Windows >> (+MinGW) from Linux. The problem happens with objects built by gcc. The >> problem is that ObjFile::CreateRegular considers a PendingComda...

The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. IIUC, these are supposed to be weak symbols but Thin LTO seems to break this in some way. This does't happen with gold or no LTO or full LTO. $ cat > a.c extern int foo(); int main() { return foo(); } $ cat > b.c int foo() { return 0; } $ clang a.c -fprofile-generate -flto=thin -c $ clang

I encountered an issue when enabling code coverage for Android and would like to confirm my findings and ask for suggestions. Here is my finding: When -fprofile-instr-generate, an llvm_prf_data section gets created that has entries for each function in the TU. One of the entries is FunctionAddr which holds the address of the function. Underneath, it is a relocation so it gets patched with the

I encountered a segfault when using lld to cross-compile for Windows (+MinGW) from Linux. The problem happens with objects built by gcc. The problem is that ObjFile::CreateRegular considers a PendingComdat to be valid (and later causes an illegal pointer dereference). The following patch fixes the crash: diff --git a/COFF/InputFiles.cpp b/COFF/InputFiles.cpp index 9e2345b0a..f47d612df 100644

I'm an idiot and sent to llvm-commits instead of llvm-dev. Fixing. On 10/17/17, 5:09 PM, "llvm-commits on behalf of Shoaib Meenai via llvm-commits" <llvm-commits-bounces at lists.llvm.org on behalf of llvm-commits at lists.llvm.org> wrote: Hi all (CC beanz for cmake advice), I'm running into a cmake problem when I try to cross-compile a