search for: _works

...d compiler-rt's > builtins library (by setting COMPILER_RT_BUILD_SANITIZERS=Off). The next steps > build Musl, libunwind, libcxx and libcxxabi. This way I'm able to "use" CMake > for every LLVM project. Setting the *_FORCED variables is roughly equivalent to setting the *_WORKS variables. I’d really like it if we didn’t need to set those. > > What isn't clear to me is whether you intend to extend your work to libunwind, > libcxx & libcxxabi because they do require a working C++ compiler too. Also, > my understanding is that the same is true for the s...

Chris, I'm fine with using JIT, but I'm trying to understand this problem: 1. My LLVM program does not produce correct results 2. Using llvm-dis, I disassemble the bytecode to C 3. I recompile using GCC and the program _works correctly_. The only odd thing is when I recompile with GCC, I see these messages: pal3.c:195: warning: conflicting types for built-in function `strcmp' pal3.c:200: warning: conflicting types for built-in function `memcpy' pal3.c:202: warning: conflicting types for built-in function `strn...

Eric Zimmerman wrote: > Chris, > > I'm fine with using JIT, but I'm trying to understand this problem: > 1. My LLVM program does not produce correct results > 2. Using llvm-dis, I disassemble the bytecode to C > 3. I recompile using GCC and the program _works correctly_. > > The only odd thing is when I recompile with GCC, I see these messages: > > pal3.c:195: warning: conflicting types for built-in function `strcmp' > pal3.c:200: warning: conflicting types for built-in function `memcpy' > pal3.c:202: warning: conflicting typ...

...004-04-14 at 18:19, Eric Zimmerman wrote: > Chris, > > I'm fine with using JIT, but I'm trying to understand this problem: > 1. My LLVM program does not produce correct results > 2. Using llvm-dis, I disassemble the bytecode to C > 3. I recompile using GCC and the program _works correctly_. > > The only odd thing is when I recompile with GCC, I see these messages: > > pal3.c:195: warning: conflicting types for built-in function `strcmp' > pal3.c:200: warning: conflicting types for built-in function `memcpy' > pal3.c:202: warning: conflicting typ...

I've hit a bug on Ubuntu 20.04. The issue occurred both with the R version that shipped with Ubuntu last week, and it is occurring now with the CRAN packages from one of the mirros (deb http://cran.mirror.garr.it/mirrors/CRAN/bin/linux/ubuntu/ focal-cran40/). The issue occurs whether I use the deb package for viridis in the Ubuntu repos, or I install it with `install.packages()` in R.

...e, please? Can you provide a minimal script with values for begin, end, n, ... etc pp or a concrete call? I got lost in your description above between what version of R from where you ran with which package or function. Keep. It. Simple. And. Concise. And reproducible. For what it is worth, it _works for me with R 4.0.0 on Ubuntu 19.10_ with the binary .deb from my PPA (as blogged about, but should be identical to what Michael built and ships via CRAN). Log of a fresh Emacs session below. I double Ubuntu 20.04 is different but "one never knows". Thank you! Dirk Log below R versio...

...erman wrote: > > Chris, > > > > I'm fine with using JIT, but I'm trying to understand this problem: > > 1. My LLVM program does not produce correct results > > 2. Using llvm-dis, I disassemble the bytecode to C > > 3. I recompile using GCC and the program _works correctly_. > > > > The only odd thing is when I recompile with GCC, I see these messages: > > > > pal3.c:195: warning: conflicting types for built-in function `strcmp' > > pal3.c:200: warning: conflicting types for built-in function `memcpy' > > pal3.c:2...

...tput of `sessionInfo`. To sum up all the additional info in my previous e-mail: the bug occurs on Ubuntu 20.04 with R 4.0.0, but does not occur on Debian, Windows, or Mac using the same version of R (R 4.0.0), and the same version of viridisLite. Best, Sam > > For what it is worth, it _works for me with R 4.0.0 on Ubuntu 19.10_ with the > binary .deb from my PPA (as blogged about, but should be identical to what > Michael built and ships via CRAN). Log of a fresh Emacs session below. I > double Ubuntu 20.04 is different but "one never knows". > > Thank you! &...

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a