search for: codespaces

Turns out compiler-rt was missing as pointed out by Kostya. Any clue why line number is not printed, It got compiled with -g -O1 along with flags specified in the link I got following lines on RHEL 6.3 clang 3.2 ==10474== ERROR: AddressSanitizer: heap-use-after-free on address 0x7fb3eb2c6b90 at pc 0x415394 bp 0x7fff49175eb0 sp 0x7fff49175ea8 READ of size 4 at 0x7fb3eb2c6b90 thread T0 #0

Thanks All In fact, to answer Pete, I was trying to do as much as possible like valgrind including as much as possible, which includes all tools. M very elated to know about ASan, given the fact that LLVM is Compile time whereas valgrind is Dynamic, need to rethink, Can you guys check this. build clang 3.2 but I got this linker error. Let me also examine closely clang++ -W -Wall

Did you checkout compiler-rt? This page has detailed info on building asan: http://code.google.com/p/address-sanitizer/wiki/HowToBuild?tm=4 --kcc On Mon, Jan 7, 2013 at 9:38 PM, Devchandra L Meetei <dlmeetei at gmail.com>wrote: > Thanks All > In fact, to answer Pete, I was trying to do as much as possible like > valgrind including as much as possible, which includes all tools.

Hi All Will LLVM be suitable for developing valgrind like tools --Regards --Dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130107/ab5ef642/attachment.html>

> Will LLVM be suitable for developing valgrind like tools It is already used by several such tools, eg ASAN, klee. Ciao, Duncan.

...o have the environment variable EDITOR point to a script you control which then runs over possible alternatives. As for the conjecture 'it is much more common to write code from ...' I would love to see some empirics across a properly surveyed R user base. The love of some power users for codespaces / devcontainers notwithstanding, 'the most common' environment for writing R code is likely still what it always was, a single windows desktop. Anyway, thanks for raising this. I can look into making the Debian (and hence Ubuntu) package switch to 'editor' over the vi fallback. D...

In X86CodeGen.cpp, the following code appears in the handler used for CALL64pcrel32 instructions: // Assume undefined functions may be outside the Small codespace. bool NeedStub = (Is64BitMode && (TM.getCodeModel() == CodeModel::Large || TM.getSubtarget<X86Subtarget>().isTargetDarwin())) || Opcode == X86::TAILJMPd;

On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > In X86CodeGen.cpp, the following code appears in the handler used for > CALL64pcrel32 instructions: > > // Assume undefined functions may be outside the Small > codespace. > bool NeedStub = > (Is64BitMode && > (TM.getCodeModel() == CodeModel::Large || >

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > >> In X86CodeGen.cpp, the following code appears in the handler used for >> CALL64pcrel32 instructions: >> >>       // Assume undefined functions may be outside the Small codespace. >>       bool NeedStub =

It looks like R has defaulted to using 'vi' for file.edit() (via EDITOR since ~24 years ago[1][2]. These days I think it is much more common to write code from lightweight environments, e.g. Docker files which strip all unnecessary commands. On such machines, it is not safe to assume 'vi' is installed, and it's not uncommon to encounter an issue like I did again today[3] where