similar to: [LLVMdev] \1 Mangled Names

I also encounter this issue and solved it locally by implementing this 2 functions. - The linux version of StartSymbolizerSubprocess uses only POSIX function and can be reused as is on OS X (maybe we should move it in a new sanitizer_symbolizer_posix.cc file) - I have a simple implementation of GetListOfModules (see the attached file) but it required 10.6 at least. That said, implementing this

I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests are failing: $ make check-ubsan … ******************** Testing Time: 2.36s ******************** Failing Tests (11): UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp

Some more information … On Jan 4, 2013, at 6:56 PM, Meador Inge wrote: > I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests > are failing: > > $ make check-ubsan > > … > > ******************** > Testing Time: 2.36s > ******************** > Failing Tests (11): > UndefinedBehaviorSanitizer ::

Hi, Indeed, the complex add is more expensive on all Cortex cores I know of. However there is an important point here that the code sequence we generate requires two registers live instead of one. In high regpressure loops, were probably losing performance. James On Wed, 11 Nov 2015 at 21:09, Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 11 November 2015 at

Hi All, I recently ran into an issue that was posted several years back on LLVMdev [1]. A brief recap of the problem is that when cross-compiling LLVM itself the configure/make scripts get confused when creating the needed build host tools. For example, building and configuring like: CC_FOR_BUILD='i686-pc-linux-gnu-gcc' CXX_FOR_BUILD='i686-pc-linux-gnu-g++'

On 11/12/2012 09:35 AM, Duncan Sands wrote: > Hi, > > On 12/11/12 15:11, Meador Inge wrote: >> On 11/11/2012 11:58 PM, Chris Lattner wrote: >> >>>> Is there a particular sub-system size that makes sense to mark as owned? I have been >>>> reworking the library call simplification infrastructure recently and will be happy >>>> to sign up as

On Aug 3, 2012, at 12:56 PM, Meador Inge <meadori at codesourcery.com> wrote: >>> An option for enabling/disabling library call simplification in `InstCombiner` >>> will be available. For backwards compatibility perhaps it should remain >>> '-simplify-libcalls'. The `NumSimplified` and `NumAnnotated` statistics shall >>> be added to

On Thu, Jul 23, 2015 at 9:53 AM, Sky Flyer <skylake007 at googlemail.com> wrote: > Hello all, > > I don't find anything helping me understand the llvm bang operator. In the > llvm TableGen language reference, it only says: > > 'TableGen also has “bang operators” which have a wide variety of meanings:' > > I would be very thankful if someone can explain it

On 08/02/2012 11:11 AM, Chris Lattner wrote: >> A new self-contained `LibCallSimplifier` class will be created. An instance >> of the class will be instantiated when running the `InstCombiner` pass. It's >> folding functionality will be invoked from `InstCombiner::tryOptimizeCall` and >> the implementation will be table-driven like `SimplifyLibCalls`. All of the

On Sun, Jan 6, 2013 at 4:03 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > I also encounter this issue and solved it locally by implementing this 2 > functions. > > - The linux version of StartSymbolizerSubprocess uses only POSIX function > and can be reused as is on OS X (maybe we should move it in a new > sanitizer_symbolizer_posix.cc file) > - I have a

Hello all, I don't find anything helping me understand the llvm bang operator. In the llvm TableGen language reference, it only says: 'TableGen also has “bang operators” which have a wide variety of meanings: *'* I would be very thankful if someone can explain it to me. e.g. what does "!strconcat" or "!if" mean? Cheers ES -------------- next part --------------

Hi, I was looking at some AArch64 benchmarks and noticed some simple cases where addresses are being folded into the address mode computations and was curious as to why. In particular, consider the following simple example: void f2(unsigned long *x, unsigned long c) { x[c] *= 2; } This generates: lsl x8, x1, #3 ldr x9, [x0, x8] lsl x9, x9, #1 str x9, [x0, x8] Given the two

On Jan 6, 2013, at 10:54 AM, Kostya Serebryany wrote: > Alex (in CC) is working on asan for OS X. I think he can handle ubsan as well. > (but give us a few days, we are all out of office due to holidays). OK, thanks. If there are no objections, then I can go ahead and commit the attached test case fix I mentioned before. Adding ALWAYS_INLINE to 'free_common' in r158885 changed

(Fixed the cfe email address) On 12/18/2015 09:34 PM, Tim Northover wrote: > On 18 December 2015 at 19:15, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It turns out that it can with some simple patches. > This sounds really cool. I think we should seriously consider putting > these patches into LLVM mainline. > >> Information on

Hi Meador, I couldn't reproduce the ASan failures on my 10.8 machine (trying that on a 10.7 one now) I'll look into making the in-process symbolizer work on OSX (which should fix some of the ubsan failures), but we do not need it in production currently, so I'm not sure when I get to it. On Mon, Jan 7, 2013 at 7:48 PM, Meador Inge <meadori at codesourcery.com> wrote: > >

On 03/18/2014 01:51 PM, Eric Christopher wrote: > I missed it coming across the first time (and that's a long time ago). > I haven't had a chance to look at it and the archives don't have the > actual patch. Can you send it? Sure. See attached. This is the same as the patch provided by Ekaterina Sanina in the thread I linked. I can build fine with this applied for the

On 12 November 2012 15:55, Meador Inge <meadori at codesourcery.com> wrote: > Another point to address is whether there can be more than one owner in a > particular area. There might be more than one code expert per area, which can be referenced by the code owner, but I wouldn't have more than one owner. Owning part of the code means you'll have to keep a sharper eye on

On Tue, Feb 21, 2012 at 4:51 AM, Jay Foad <jay.foad at gmail.com> wrote: > All, > > This buildbot is getting lots of assertion failures in the test suite. > They were probably caused by my commit: > > ------------------------------------------------------------------------ > r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines > Changed paths: >

On Nov 11, 2012, at 12:44 AM, Chris Lattner wrote: > > On Nov 10, 2012, at 10:43 AM, Joe Abbey <jabbey at arxan.com> wrote: > >> Hello, >> >> Chris's "keynote" at the LLVM Developers' Conference included a call for code owners, and my company has a heavy dependency on Bitcode, I propose taking ownership of: >> >> lib/Bitcode/*

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify