similar to: [LLVMdev] LLVM asserts

On Aug 19, 2009, at 9:02 AM, Kenneth Uildriks wrote: > How do you get LLVM methods to return or throw an error to the > caller's code rather than aborting the process? I'd like my compiler > to be able to print diagnostic messages, including language source > lines, whenever LLVM reports a problem. Hi Kenneth, Recoverable errors are handled with

On Wednesday 19 August 2009 11:29, Chris Lattner wrote: > On Aug 19, 2009, at 9:02 AM, Kenneth Uildriks wrote: > > How do you get LLVM methods to return or throw an error to the > > caller's code rather than aborting the process? I'd like my compiler > > to be able to print diagnostic messages, including language source > > lines, whenever LLVM reports a

Please email llvmdev, not me directly. On Aug 19, 2009, at 9:37 AM, Kenneth Uildriks wrote: > So things like type mismatches, missing return statements, and whatnot > count as "internal errors"? I guess that makes sense... I'll just > have to do those check on my side then. Yes. The IR has to be well formed by your frontend. -Chris > > On Wed, Aug 19, 2009 at

On Wed, Aug 19, 2009 at 2:34 PM, David Greene<dag at cray.com> wrote: > On Wednesday 19 August 2009 11:29, Chris Lattner wrote: >> On Aug 19, 2009, at 9:02 AM, Kenneth Uildriks wrote: >> > How do you get LLVM methods to return or throw an error to the >> > caller's code rather than aborting the process?  I'd like my compiler >> > to be able to

On Aug 19, 2009, at 7:29 PM, Óscar Fuentes wrote: Eli Friedman <eli.friedman at gmail.com> writes: > Besides, in my experience all LLVM asserts I see are Type mismatches > for > instructions and similar cases, i.e., errors about my compiler > producing > wrong LLVM "code" through the API, plus some occasional bug on LLVM, > sometimes about one layer passing

On 19/08/2009, at 18.42, Chris Lattner wrote: > Please email llvmdev, not me directly. I have done that too recently. Did Mailman stop setting the ReplyTo header?

On Aug 19, 2009, at 12:23 PM, Jakob Stoklund Olesen wrote: > > On 19/08/2009, at 18.42, Chris Lattner wrote: > >> Please email llvmdev, not me directly. > > I have done that too recently. Did Mailman stop setting the ReplyTo > header? > Apparently it mysteriously was changed. I have fixed this so it should direct you to reply to the list. -Tanya >

> To be fully clear, I'm not a big fan of the current llvm_report_error > approach (though it is definitely better than what we had before!). > In my ideal little world, when the backend invokes llvm_report_error, > it should *guarantee* that it can continue on and return back.  For > example, in an inline asm error, I think the code generator should > report the error with

Hi All, I've been thinking lately about how to improve LLVM's error model and error reporting. A lack of good error reporting in Orc and MCJIT has forced me to spend a lot of time investigating hard-to-debug errors that could easily have been identified if we provided richer error information to the client, rather than just aborting. Kevin Enderby has made similar observations about the

My front-end is sync'd with the trunk now, and working well, but it required some additional functions exposed in the C bindings. I hereby submit them for review and approval for inclusion in the trunk. -------------- next part -------------- A non-text attachment was scrubbed... Name: cbindings.patch Type: application/octet-stream Size: 7269 bytes Desc: not available URL:

On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Kenneth Uildriks wrote: >>> >>> You're right, I hadn't thought this through. The whole point of making >>> them >>> local is to say that "I'm sure these callees won't modify that memory" >>> regardless of what functions actually get called,

On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > My front-end is sync'd with the trunk now, and working well, but it > required some additional functions exposed in the C bindings.  I > hereby submit them for review and approval for inclusion in the trunk. > LLVMGetAttribute had a bug in it. Here's the revised version of the patch

On Wed, Aug 19, 2009 at 5:27 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > As LLVM is really a library it should behave like one and not just abort the > whole process on an assert. This isn't Java; if we hit an assert, it's likely memory is in an inconsistent state, so we don't want to try to recover. -Eli

On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: > Unfortunately, yes.  See PR4542.  Progress has been made recently > though -- the optimizers are now ready.  The main things left to do > is to update the documentation and update the testsuite to account > for the change in the meaning of a module without a targetdata string. > > Dan > > So

On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >> A better way for a front-end to declare that vtbl-ptr-hacking is not >> expected and not supported is for it to emit llvm.invariant.start and >> llvm.invariant.end calls for it. > > Some of us were talking about this apropos your

Eli Friedman <eli.friedman at gmail.com> writes: >> As LLVM is really a library it should behave like one and not just abort the >> whole process on an assert. > > This isn't Java; if we hit an assert, it's likely memory is in an > inconsistent state, so we don't want to try to recover. This over-used argument about "memory likely is in an inconsistent

On Oct 6, 2009, at 5:47 PM, Kenneth Uildriks wrote: > On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks > <kennethuil at gmail.com> wrote: >> My front-end is sync'd with the trunk now, and working well, but it >> required some additional functions exposed in the C bindings. I >> hereby submit them for review and approval for inclusion in the >> trunk.

Hello, Jakob > I have done that too recently. Did Mailman stop setting the ReplyTo > header? Yes. So, now you should use "reply all", not "reply". It's quite hard to change the habits :( -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > It would be unfortunate in a way if "this instruction can trap and go > there" is taken to mean "if this instruction has no effect other than > a possible trap, the instruction and the trapping behavior *must* be > preserved". What exactly would the semantics be if the

On Thu, May 27, 2010 at 6:38 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Thu, May 27, 2010 at 5:47 PM, Evan Shaw <chickencha at gmail.com> wrote: >> I'm writing a frontend with the LLVM C bindings for a language that >> has a goto statement, similar to C's. I'm having some trouble figuring >> out what to do for the case where the label is