similar to: [LLVMdev] [Patch] WinCOFFObjectWriter: fix for storing pointer to string table in header name field

Is there a problem if the string is not null terminated? If not, you can snprintf it right into place instead of doing sprintf+mempcy. On Tue, Jul 23, 2013 at 12:29 PM, Paweł Bylica <pawel.bylica at ibs.org.pl>wrote: > Hi, > > Recently I was hit by an assert in WinCOFFObjectWriter that had forbidden > storing pointer to string table in header name field when the pointer had

In article <CACs=ty+7zKZU6Ad4jZ5J5Rb0qoMa-bNtO0f+xK_8SYfy3RyFbg at mail.gmail.com>, Reid Kleckner <rnk at google.com> writes: > Is there a problem if the string is not null terminated? If not, you can > snprintf it right into place instead of doing sprintf+mempcy. Am I the only one who scratches my head and says: sprintf? memcpy? Why are we using error-prone C APIs in

On 23.07.2013 18:43, Reid Kleckner wrote: > Is there a problem if the string is not null terminated? If not, you can > snprintf it right into place instead of doing sprintf+mempcy. snprintf always null-terminates (and truncates if there's not enough space). -Nico

On Tue, Jul 23, 2013 at 12:48 PM, Nico Rieck <nico.rieck at gmail.com> wrote: > On 23.07.2013 18:43, Reid Kleckner wrote: > >> Is there a problem if the string is not null terminated? If not, you can >> snprintf it right into place instead of doing sprintf+mempcy. >> > > snprintf always null-terminates (and truncates if there's not enough > space).

On Tue, Jul 23, 2013 at 5:53 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Yes. What you are seeing are the platform checks, where the build system > looks for the presence of functions, headers, etc and then generates a > configuration file with that information. I've been meaning to cut down on the number of these because they are super slow and wasteful. Some of them are

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”.

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Friday, May 22, 2015 8:45:11 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > > > > Any comments? Not in particular, but I think we're pretty close to applying a rewrite by Jonas Paulsson

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Paweł Bylica" <chfast at gmail.com> > Sent: Wednesday, July 1, 2015 6:42:41 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what to

Hello everyone, I need some advises about (re)using ExecutionEngine with MCJIT as a driver. I'm developing a service that receives a piece of high-level code, compiles it into LLVM IR function "main" and uses MCJIT to execute the function. It can happen that the same piece of code is sent to the service many times. I would like to cache the results (keep generated machine code

Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Mon, Jun 20, 2016 at 05:05:18PM +0000, Paweł Bylica via llvm-dev wrote: >> On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: >> >> > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: >> > > Hi LLVM, >> > > >>

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Paweł Bylica" <chfast at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, July 1, 2015 12:08:37 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what

On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: > > Hi LLVM, > > > > I want to complain a bit about the quality of the code included in the > > public LLVM headers. For projects that depend on LLVM is really hard to > > just include LLVM headers not to

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Jonas Paulsson" <jonas.paulsson at ericsson.com> > Sent: Friday, May 22, 2015 9:19:14 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > >

On Tue, Jun 30, 2015 at 11:03 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Paweł Bylica" <chfast at gmail.com> > > To: "David Majnemer" <david.majnemer at gmail.com> > > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu> > > Sent: Tuesday, June 30, 2015 5:42:24 AM > > Subject: Re:

ping From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Tuesday, August 28, 2012 11:10 AM To: Jim Grosbach; Pawel Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] RFC: MCJIT enhancements Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent:

Hi, I'm interested in any information about implementations of switch instruction and its runtime cost. If it's very target dependent, I'm mostly care about X86. Pointing some LLVM code is also good. - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/285f02e5/attachment.html>

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Friday, August 17, 2012 7:51 AM To: Paweł Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu); Kaylor, Andrew Subject: Re: [LLVMdev] RFC: MCJIT enhancements On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl<mailto:pawel.bylica at ibs.org.pl>>

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

On Mon, May 9, 2016 at 4:46 PM Sylvestre Ledru <sylvestre at debian.org> wrote: > Le 09/05/2016 à 07:34, Paweł Bylica a écrit : > > llvm-3.8-dev is broken: > > > > CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include): > > include could not find load file: > > > > /usr/share/llvm/cmake/LLVMExports.cmake > Brad King helped me