similar to: [LLVMdev] -f[no-]omit-frame-pointer

On Tue, Dec 27, 2011 at 11:48 AM, Kostya Serebryany <kcc at google.com> wrote: > Hi, > > It looks like the default for -fomit-frame-pointer has recently changed from > "no" to "yes at O1 and higher", but I did not see the commit. > Was that intentional? Yes; r146586. -Eli

On Tue, Dec 27, 2011 at 12:06 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Tue, Dec 27, 2011 at 11:48 AM, Kostya Serebryany <kcc at google.com> > wrote: > > Hi, > > > > It looks like the default for -fomit-frame-pointer has recently changed > from > > "no" to "yes at O1 and higher", but I did not see the commit. > >

On Tue, Dec 27, 2011 at 12:22 PM, Joerg Sonnenberger < joerg at britannica.bec.de> wrote: > On Tue, Dec 27, 2011 at 12:10:54PM -0800, Kostya Serebryany wrote: > > What would be the best fix for asan? > > Can you be explicit what you need to asan? Just the equivalent of > __builtin_return_address(0) or do you really need a full stack trace? > asan-rt uses

> What would be the best fix for asan? > Force -mdisable-fp-elim when asan is enabled or document that asan > requires -fomit-frame-pointer for better warning messages? Just messages? I would suggest documentation. If it is needed by some of the checks then enabling frame pointers by default when asan is enabled and rejecting or warning when someone tries to use both asan and

On Tue, Dec 27, 2011 at 12:35:52PM -0800, Kostya Serebryany wrote: > On Tue, Dec 27, 2011 at 12:22 PM, Joerg Sonnenberger < > joerg at britannica.bec.de> wrote: > > > On Tue, Dec 27, 2011 at 12:10:54PM -0800, Kostya Serebryany wrote: > > > What would be the best fix for asan? > > > > Can you be explicit what you need to asan? Just the equivalent of >

On Wed, Dec 28, 2011 at 12:35 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Wed, Dec 28, 2011 at 2:06 AM, Anton Korobeynikov < > anton at korobeynikov.info> wrote: > >> > I believe the best option for us is to add the >> > --fno-omit-frame-pointer depending on the -faddress-sanitizer flag. >> > But in order to do this reliably, we need

On Tue, Dec 27, 2011 at 12:10:54PM -0800, Kostya Serebryany wrote: > What would be the best fix for asan? Can you be explicit what you need to asan? Just the equivalent of __builtin_return_address(0) or do you really need a full stack trace? Joerg

On Wed, Dec 28, 2011 at 12:35 AM, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Dec 27, 2011 at 12:22 PM, Joerg Sonnenberger > <joerg at britannica.bec.de> wrote: >> >> On Tue, Dec 27, 2011 at 12:10:54PM -0800, Kostya Serebryany wrote: >> > What would be the best fix for asan? >> >> Can you be explicit what you need to asan?

> I believe the best option for us is to add the > --fno-omit-frame-pointer depending on the -faddress-sanitizer flag. > But in order to do this reliably, we need to remove all the instances > of -fomit-frame-pointer from the command line. Why? Just add -fno-omit-frame-pointer last. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State

On Wed, Dec 28, 2011 at 2:06 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > I believe the best option for us is to add the > > --fno-omit-frame-pointer depending on the -faddress-sanitizer flag. > > But in order to do this reliably, we need to remove all the instances > > of -fomit-frame-pointer from the command line. > Why? Just add

I've been building clang on linux for a couple of years now, contributing to the testing on Ubuntu, but this one has me stumped: fatal error: 'asm/socket.h' file not found #include <asm/socket.h> [1556/4006] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_platform_limits_posix.cc.o FAILED:

Well I decided that 2am on a thursday night would be a good time to try this and I've hit a wall... most of the other errors were pretty easy to fix. I just don't understand this one: --snip--snip--snip-- gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > Just want to remind everyone that we plan to stop using mach_override in > > asanin favor of OSX's native function interposition. > > So, we probably don't want to spend too much effort fixing

Dmitrii, all, Please note, that GCC 5.3 had a significant update to the MPX code quality - please, use this version as reference. Regards, Sergos On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com> wrote: > >> >> >> On Thu, Feb

On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii < Dmitrii.Kuvaiskii at tu-dresden.de> wrote: > >> Recently I played with MPX support on Intel C/C++ Compiler (icc). This > >> implementation looks *much* better, with the following example > >> overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on > >> "streamcluster".

Hello, even though the study of Intel MPX took much longer than expected, we have finally finished it. Currently, it is published in two formats: * as a technical report: https://arxiv.org/abs/1702.00719 * and as a webpage: https://intel-mpx.github.io/ This work contains evaluation of MPX from perspectives of performance (Phoenix, PARSEC, and SPEC benchmark suites), security (RIPE and found

On Feb 7, 2012, at 4:04 PM, Kostya Serebryany wrote: > On Tue, Feb 7, 2012 at 3:46 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: > > Slightly formatted/commented patch. > > WDYT? > > This seems to work fine, except that reading a field from a const > AttrConst is not a constant expression in C++03, so the

No, not that I am aware of. On Nov 14, 2013, at 10:15 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. > > Is AddressSanitizer involved in

I don’t know yet, but I will let you know as soon as I can. On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> No, not that I am aware of. > > So, if my commits did indeed trigger the failures it could be > something like binary size change that caused