similar to: sizeof(DIFlags)

Regarding flags, I was just thinking that maybe we should invent a new DISubprogramFlags type. DISubprogram already has a few bitfields for subprogram-specific things, Fortran will want 3 more, and there's no reason to fill up the generic DIFlags with more bits that are used in only one class. I agree that the array stuff needs to be designed with an eye to handling how other languages do

[Resending due to accidental markdown rendering - sorry] Hi list, Let's talk about adding a new type of debug info metadata. Here are the steps (at minimum - probably incomplete) one needs to take: 1. Create a new class in the hierarchy 2. Implement two forms of `MD_NODE_GET` 3. Specialize `MDNodeKeyImpl` 4. Modify `LLParser.cpp` and add serialization code for your special type5. Modify

> On May 29, 2018, at 12:28 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +some of the debug info cabal (& Duncan, as an emeritus member, and person who plumbed a lot of the current debug info syntax support in) > > Visitor seems plausible though I haven't looked at the code in detail to see if it'd work perfectly. > > On Tue, May 29, 2018 at 7:56

+some of the debug info cabal (& Duncan, as an emeritus member, and person who plumbed a lot of the current debug info syntax support in) Visitor seems plausible though I haven't looked at the code in detail to see if it'd work perfectly. On Tue, May 29, 2018 at 7:56 AM Sohail Somani (Fizz Buzz Inc.) via llvm-dev <llvm-dev at lists.llvm.org> wrote: > [Resending due to

Thanks all for your response. On Tue, May 29, 2018, at 5:38 PM, Duncan P. N. Exon Smith wrote: > > >> On May 29, 2018, at 12:55, Adrian Prantl <aprantl at apple.com> wrote: >> >> >> >>> On May 29, 2018, at 12:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> +some of the debug info cabal (& Duncan, as an

> On May 29, 2018, at 12:55, Adrian Prantl <aprantl at apple.com> wrote: > > > >> On May 29, 2018, at 12:28 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> +some of the debug info cabal (& Duncan, as an emeritus member, and person who plumbed a lot of the current debug info syntax support in) >>

> Could you please describe what is the benefit of that? Currently there are two ways to provide DISPFlagDefinition, via bool and SPFlag, I would like to make it only via SPFlags, it will be NFC and it will make the changes in parser simpler for moving five flags from from DIFlags to DISPFlags. Currently parser checks the presence of SPFlags to see if the definition is present in bool or spflag

Yes, removing the support for isLocal, isDefinition fields completely from ll files, currently the LLParser still parses it. I want to remove it and update the all the ll files which still uses it. Also the metadata read will support old format, no changes in that. so if ll file has isLocal and isDefinition it will result in parser error. But the bitcode read will work as usual. - Chirag.

Hello, In regard to the review request https://reviews.llvm.org/D74470, I am trying to move five of the DIFlags to DISPFlag for the moment namely DIFlagExplicit, DIFlagPrototyped, DIFlagNoReturn, DIFlagThunk, DIFlagAllCallsDescribed. The llvm ir format for DISubprogram currently has backword compatibility where the isLocal, isDefinition, virtuality, isOptimized and SPFlags are mutually exclusive.

Adding tags on subject line From: Chirag Patel Sent: 22 August 2018 11:20 To: llvm-dev at lists.llvm.org Subject: DIBuilder missing interface to generate DWARF info for packed_decimal basic type. Hello, I am working on a llvm based compiler frontend in which, I am using the packed_decimal type encoding. During using the llvm DIBuilder, I found out that the interface to create BasicType with

On 11-06-12 7:40 PM, John McCall wrote: > On Jun 12, 2011, at 2:14 PM, Cameron Zwarich wrote: > >> > On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote: >> > >>> >> Hi Sohail, >>> >> >>>> >>> Is LLVM expressive enough to represent asynchronous exceptions? >>> >> >>> >> not currently. The

Hello Paul, Thanks for the reply. Yes, I am only looking for dwarf support at the moment and planning to support both PLI/COBOL decimal types. Also thanks for the suggestion, you are right as it is going to be rare cases, so it will be better to implement a separate subclass to avoid memory overhead for others. >> (Somebody is actively working on scaled binary operations, although they

On 11-06-12 8:53 PM, John McCall wrote: >> > The CFG point is a valid point. In what I've read on the topic so far >> > (yay Internet), it seems like the CFG would have to represent the fact >> > that control can jump to a handler after nearly every instruction in the >> > presence of async exceptions. The Hotspot compiler probably does this. >> >

Is LLVM expressive enough to represent asynchronous exceptions? --------------------------------------------------------------- Summary: Need new LLVM instructions or extending of all instructions. C++ exceptions are synchronous: the compiler knows when/where they are being raised. Asynchronous exceptions can be raised at any time. For example, an integer divide-by-zero may raise an

> On May 29, 2018, at 15:33, Sohail Somani (Fizz Buzz Inc.) <sohail at fizzbuzzinc.com> wrote: > > Thanks all for your response. > > On Tue, May 29, 2018, at 5:38 PM, Duncan P. N. Exon Smith wrote: >> >> >>> On May 29, 2018, at 12:55, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>> >>>> On May 29,

On Jun 12, 2011, at 5:31 PM, Sohail Somani wrote: > On 11-06-12 7:40 PM, John McCall wrote: >> On Jun 12, 2011, at 2:14 PM, Cameron Zwarich wrote: >> >>>> On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote: >>>> >>>>>> Hi Sohail, >>>>>> >>>>>>>> Is LLVM expressive enough to represent asynchronous

On 11-06-12 12:01 AM, Sohail Somani wrote: > Is LLVM expressive enough to represent asynchronous exceptions? > --------------------------------------------------------------- > > Summary: Need new LLVM instructions or extending of all instructions. > > C++ exceptions are synchronous: the compiler knows when/where they are > being raised. > > Asynchronous exceptions can

On Mon, Oct 3, 2016 at 2:24 PM Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Sep 30, 2016, at 4:05 PM, Victor Leschuk <vleschuk at accesssoftek.com> > wrote: > > > > Hello Adrian, sorry for the delay with the response. Somehow I missed > your message.. > > > > On 09/13/2016 12:43 AM, Adrian Prantl wrote: >

This renables the ability for Ruby 1.8 environments to perform reexecs --- lib/unicorn/http_server.rb | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb index 2decd77..9a5795c 100644 --- a/lib/unicorn/http_server.rb +++ b/lib/unicorn/http_server.rb @@ -449,13 +449,14 @@ class Unicorn::HttpServer end

Hello, many of our platforms do not have a integrated floppy, some even don''t have a floppy controller. As pxelinux still has a problem with machines without a floppy in combination with some bios versions I need to chainload a different bootstrap loader which works on the floppyless platforms. But I also need to load a BartPE and the other BS loader does not support that. So I tried to