similar to: [LLVMdev] Setting up array ordering dwarf for arrays

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Setting up array ordering dwarf for arrays"

2013 Oct 03
0
[LLVMdev] Setting up array ordering dwarf for arrays
Not at the moment, we've been adding things that need additions to the metadata on an "as needed" basis. Do you have a language that allows you to swap orderings in source code? If so, then feel free to add it to the array type metadata and send a patch. -eric On Oct 3, 2013 1:15 PM, "sebastien deldon (PGI)" < sebastien.deldon at pgroup.com> wrote: > Hi all,****
2013 Oct 04
1
[LLVMdev] Setting up array ordering dwarf for arrays
Usually the array ordering is implied by the language; for example LLVM supports Fortran via Dragonegg but we still don't set the ordering explicitly, we rely on the debugger to assume the right ordering because of the language code. You wouldn't need to set ordering unless you want an ordering that isn't the language default, or you're using a language code that the debugger
2014 Jan 27
3
[LLVMdev] Debug information for outlined routine
Hi all, I would like to know how can I express debug information for an outlined function using llvm debug metadata. I mean I have a function f() and part of its code is outlined in a new function g() . I would like to generate llvm debug metadata so that when stepping in g() the debugger step in original sources lines from f() routine ? Thanks for your help Seb
2013 Sep 16
2
[LLVMdev] Question about debug metadata
Hi all, What is retained type list designed for in debug metadata ? Thanks for your answer Seb ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
2013 Sep 16
0
[LLVMdev] Question about debug metadata
It's designed to deal with types that may not be referenced via other metadata. Anonymous metadata not referenced by named metadata will be automatically removed. -eric On Mon, Sep 16, 2013 at 4:18 AM, sebastien deldon (PGI) <sebastien.deldon at pgroup.com> wrote: > Hi all, > > > > What is retained type list designed for in debug metadata ? > > > > Thanks for
2016 May 26
3
Adapting and open-sourcing PGI's Fortran frontend for LLVM
Hi Chad - We have a functional Fortran compiler, with the PGI front-end bridged directly to LLVM, all of our Fortran runtime libraries integrated, and the Clang driver adapted for use with the Fortran compiler. We're working with a few users at DOE who are trying to compile big applications with a binary version of the compiler. Work is ongoing to migrate the source code into an LLVM-style
2016 May 26
0
Adapting and open-sourcing PGI's Fortran frontend for LLVM
Hi Chad, I can tell you that progress is being made on PGI's side; I'll let Doug/Rob provide more detailed updates. -Hal ----- Original Message ----- > From: "Chad Rosier" <mcrosier at codeaurora.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "flang-dev" <flang-dev at googlegroups.com>, "douglas miles (PGI)"
2016 May 26
2
Adapting and open-sourcing PGI's Fortran frontend for LLVM
Hi Hal, I haven't been following this closely, but has there been any updates recently. Regards, Chad -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Sunday, November 15, 2015 12:46 AM To: Hal Finkel <hfinkel at anl.gov> Cc: LLVM Dev <llvm-dev at lists.llvm.org>; flang-dev <flang-dev at
2016 May 26
2
Adapting and open-sourcing PGI's Fortran frontend for LLVM
> On May 26, 2016, at 1:57 PM, Neely, Rob via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Chad, et al, > > In addition to Doug’s excellent technical update, I’ll note that we are > starting to have some discussions on the DOE side with PGI about > establishing a more formal review team made up of some key LLVM > stakeholders to help smooth the way for a broader
2016 May 26
0
Adapting and open-sourcing PGI's Fortran frontend for LLVM
Chad, et al, In addition to Doug’s excellent technical update, I’ll note that we are starting to have some discussions on the DOE side with PGI about establishing a more formal review team made up of some key LLVM stakeholders to help smooth the way for a broader public rollout of the Flang code base and eventual integration. We’ll probably rely on Hal and others here to help us figure out who
2016 May 27
1
Adapting and open-sourcing PGI's Fortran frontend for LLVM
This process is certainly only open to a select group, so pragmatically it's closed. I can understand that it will certainly not be an easy process once it's public due to the amount of code and complexity. Maybe someone can comment on a specific issue - When we ported our Fortran front-end to target llvm, we found that Fortran ENTRY doesn't map very well to llvm ir. Can anyone who
2014 Jan 27
2
[LLVMdev] Debug information for outlined routine
----- Original Message ----- > From: "David Blaikie" <dblaikie at gmail.com> > To: "sebastien deldon (PGI)" <sebastien.deldon at pgroup.com>, "Eric Christopher" <echristo at gmail.com> > Cc: "llvmdev" <llvmdev at cs.uiuc.edu> > Sent: Monday, January 27, 2014 10:12:27 AM > Subject: Re: [LLVMdev] Debug information for
2016 May 26
0
Adapting and open-sourcing PGI's Fortran frontend for LLVM
No closed doors intended here. Just a recognition that for something like an initial review to be useful, we probably have to be a bit careful in how many people we can reasonably involve before it could get unwieldy, and trying to be respectful of people’s time if we can nail down 90% of issues with a smaller group before going broader. I think we’d be fine with opening up the WebEx presentations
2015 Nov 13
7
Adapting and open-sourcing PGI's Fortran frontend for LLVM
Hi everyone, I have some very good news for everyone interested a production-quality Fortran frontend for LLVM: The U.S. Department of Energy’s National Nuclear Security Administration and its three national labs have reached an agreement with NVIDIA's PGI division to adapt and open-source PGI's Fortran frontend, and associated Fortran runtime library, for contribution to the LLVM
2015 Nov 14
2
Adapting and open-sourcing PGI's Fortran frontend for LLVM
----- Original Message ----- > From: "Alex Bradbury" <asb at asbradbury.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>, "flang-dev" <flang-dev at googlegroups.com>, "Rob Neely" <neely4 at llnl.gov>, > "douglas miles (PGI)" <douglas.miles at
2014 Jan 27
2
[LLVMdev] Debug information for outlined routine
Yes I agree with David, I don't think we can draw analogy between lambda and outlined routines. Seb From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Monday, January 27, 2014 5:51 PM To: Hal Finkel Cc: llvmdev; sebastien deldon (PGI); Eric Christopher Subject: Re: [LLVMdev] Debug information for outlined routine > Given that LLVM has no current support for outlining I don't
2013 Feb 07
3
[LLVMdev] Is there a way to verify that debug info metadata are correct ?
Hi all, I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. On my example I got llc 3.2 to fail on following assertion: llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU
2015 Nov 15
0
Adapting and open-sourcing PGI's Fortran frontend for LLVM
> On Nov 13, 2015, at 2:22 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi everyone, > > I have some very good news for everyone interested a production-quality Fortran frontend for LLVM: > > The U.S. Department of Energy’s National Nuclear Security Administration and its three national labs have reached an agreement with NVIDIA's PGI
2009 Feb 11
1
Problem with R using pgi compiler on x86_64
Hi, we have installed R-2.8.1 using the current pgi compiler (8.0.2) for AMD64 on a SLES9 system. When I try to install "Matrix" everything is fine until the last step. make[1]: Leaving directory `/tmp/R.INSTALL.TW3399/Matrix/src/AMD' pgCC -L/usr/lib64 -L/usr/X11R6/lib64 -pgf90libs -o Matrix.so CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o
2013 Nov 06
1
[LLVMdev] how to avoid llvm to optimize variable
Hi all, For debugging purpose, I would like to create temporary local variables that I want to keep 'live' for a routine execution. They will be set to a value at routine entrance and I they will never be used. Is there a way to avoid llvm to optimize them away when mem2reg is performed ? Thanks for your answer Seb