search for: pirama

...reproducer for further investigation. (I omitted it to avoid manually packaging a whole set of object files - I think --reproduce=<repro> doesn't work on Windows yet). For reference, here's the segfault: #0 0x0000000000500999 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /ssd2/pirama/ll$ m-upstream/llvm/lib/Support/Unix/Signals.inc:488:11 #1 0x0000000000500b49 PrintStackTraceSignalHandler(void*) /ssd2/pirama/llvm-upstream$ llvm/lib/Support/Unix/Signals.inc:552:1 #2 0x00000000004ff1d6 llvm::sys::RunSignalHandlers() /ssd2/pirama/llvm-upstream/llvm$ lib/Support/Signals.cpp:66:5 #3...

...of work to do. 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...

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) > Targ...

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, >...

...at google.com> 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:...

...erator 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 Nain...

On Wed, May 9, 2018 at 6:43 AM Teresa 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...

...; >> 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....

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-unknown-linux-gnu Thread model: posix InstalledDir: /ssd2/pirama/llvm-upstream/llvm-release/bin/. $ ./ld.lld --version LLD 7.0.0 (https://git.llvm.org/git/lld.git dc4977e104c7f33758ac6119d1528aafcd8a94dc) (compatible with GNU linkers) On Wed, May 9, 2018 at 6:44 AM Teresa Johnson <tejohnson at google.com> wrote: > > > On Wed, May 9, 2018 at 6:...

...do not specify all necessary libraries to ensure proper linking of the discarded sections. Question: I'm considering setting FunctionAddr to 0 if value profiling is disabled (or omitting llvm_prf_data altogether if it exists solely for value profiling). Does that sound reasonable? Thanks, -Pirama -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191202/37daea6f/attachment.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_filen...

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

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

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