search for: l91

Dear R community, I am new to R, a reforming SAS user :) I am running R 2.10.1 on a Windows XP machine. I would like to write linear functions of my coefficient parameter estimates from a glm, but am having a difficult time understanding the parameterization R uses. In the toy example below I am running a glm on binomial data, with clones and lines within clones as fixed effects, each with 6

...But I couldn't work out if these are expected leaks in the libosinfo code (in which case we should suppress them), or if they are actual bugs because we are missing a true destructor here: https://github.com/libguestfs/virt-v2v/blob/8e870da79b5a61513f568b0b81c773084b8d7997/v2v/libosinfo-c.c#L91 Perhaps there's a reason why we cannot have a destructor, for example that the C database is supposed to hold references to the OS objects? Unfortunately we never free the database. It could be that to express this properly we'd need to expose (db, os) tuples to the OCaml garbage collecto...

2018-06-01 2:06 GMT-05:00 Alex Denisov <1101.debian at gmail.com>: > If there are any other hints: send them my way :) Debug with gdb, but a breakpoint at https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Utils/SymbolRewriter.cpp#L91. It should hit twice (which is the error reported). At each break you can look at where the machine code is coming from (e.g. a shared object), and which static analyzer calls it. Michael

...IIRC. Do you still get the same issues if you export G_SLICE=always-malloc when running valgrind? > or if they are actual bugs because we are > missing a true destructor here: > > https://github.com/libguestfs/virt-v2v/blob/8e870da79b5a61513f568b0b81c773084b8d7997/v2v/libosinfo-c.c#L91 > > Perhaps there's a reason why we cannot have a destructor, for example > that the C database is supposed to hold references to the OS objects? This is correct according to the way we use OsinfoOs so far, i.e. only by using what OsinfoDb has, because OsinfoDb holds references on th...

On 31 May 2018 at 08:41, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I understand the linking problem. What I do not understand is how to debug the difference between two versions of compilers. > This what I do (briefly): > > clang++-4 foobar.cpp -lLLVM -l/opt/llvm-3.9/lib > > clang++-5 foobar.cpp -lLLVM -l/opt/llvm-3.9/lib If you add -v then Clang will

Is anybody using the LLVM/clang/lldb compiled with the MSVC 2019 (x86-32bit) successfully? I am getting crash in SmallVector at multiple places after a llvm:SmallVector is being moved around in move constructor or move operator=. Not sure what is going on. ~SmallVectorImpl() { if (!this->isSmall()) free(this->begin()); // <=== crash here, line 336 SmallVector.h } The

Hello everyone, I observe a weird behavior switching from clang-4 to clang-5 (and any higher version). I compile an executable that depends on LLVM. Everything works fine with clang-4, but when I run the executable compiled with clang-5 I see the following error: : CommandLine Error: Option 'rewrite-map-file' registered more than once! LLVM ERROR: inconsistency in registered CommandLine

Much similar to unlink_on_exit, but recursively cleaning directories. --- mllib/common_utils.ml | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/mllib/common_utils.ml b/mllib/common_utils.ml index 3943417..f49ede6 100644 --- a/mllib/common_utils.ml +++ b/mllib/common_utils.ml @@ -386,6 +386,35 @@ let unlink_on_exit = registered_handlers := true )