similar to: [LLVMdev] how to avoid llvm to optimize variable

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

Hi all, Is there a way to set up array ordering (DW_ORD_row_major or DW_ORD_col_major) using debug metadata ? Best Regards 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.

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

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

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

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

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

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

> 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

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

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

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

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

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

Hi Renato, It's definitively not A15. Can this be the case that NEON units for cortex-A9 support it but isn't documented/recommended ? And as mentioned before code is working ! Seb > -----Original Message----- > From: rengolin at gmail.com [mailto:rengolin at gmail.com] On Behalf Of > Renato Golin > Sent: Friday, November 09, 2012 6:27 PM > To: Sebastien DELDON-GNB >

On Thu, Feb 7, 2013 at 3:12 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > 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. If at all possible please migrate to using the DIBuilder interface. I'm trying to port DragonEgg over to