similar to: [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,****

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

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

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

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

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

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)"

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

> 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

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

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

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

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

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

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

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

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

> 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

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

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