similar to: [LLVMdev] Using thin archives when building llvm

On 17 July 2015 at 07:19, Brad King <brad.king at kitware.com> wrote: > On 07/15/2015 09:00 PM, Rafael Espíndola wrote: >> I have just committed support to llvm-ar for creating thin archives. >> The idea of thin archives is that they contain just the symbol table >> and the path to find the original .o files. > > Neat! Is this expected to be used only for

On 20 July 2015 at 10:53, Brad King <brad.king at kitware.com> wrote: > On 07/20/2015 10:48 AM, Rafael Espíndola wrote: >>>> Setting CMAKE_CXX_CREATE_STATIC_LIBRARY works on OS X and linux, but >>>> on windows I still see a call to "lld-link2 /lib..." when >>>> CMAKE_CXX_CREATE_STATIC_LIBRARY is set to use llvm-lib. >> >> I was

> CMake has undocumented variables set by the Modules/Platform/* > files to specify the rules for creating archives. These are: > > CMAKE_<LANG>_ARCHIVE_{CREATE,APPEND,FINISH} > > for creating, appending to, and finishing an archive. For > tools/platforms that do not support separate steps we also > have: > > CMAKE_<LANG>_CREATE_STATIC_LIBRARY Setting

On 20 July 2015 at 09:00, Brad King <brad.king at kitware.com> wrote: > On 07/17/2015 02:44 PM, Rafael Espíndola wrote: >> Setting CMAKE_CXX_CREATE_STATIC_LIBRARY works on OS X and linux, but >> on windows I still see a call to "lld-link2 /lib..." when >> CMAKE_CXX_CREATE_STATIC_LIBRARY is set to use llvm-lib. > > What CMake generator are you using on

> The Modules/Platform/Windows-MSVC.cmake module unconditionally > sets CMAKE_CXX_CREATE_STATIC_LIBRARY and uses CMAKE_LINKER. > As mentioned earlier the CMAKE_<LANG>_CREATE_STATIC_LIBRARY > and similar variables are internal implementation details > that are not meant to be set by users or project code. That > is why the above works only on certain platforms. > >

On 18/11/2015 06:47, Ming Lin wrote: > @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) > } > > start_sqs = nvme_cq_full(cq) ? 1 : 0; > - cq->head = new_head; > + /* When the mapped pointer memory area is setup, we don't rely on > + * the MMIO written values to update the head pointer. */ >

On 18/11/2015 06:47, Ming Lin wrote: > @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) > } > > start_sqs = nvme_cq_full(cq) ? 1 : 0; > - cq->head = new_head; > + /* When the mapped pointer memory area is setup, we don't rely on > + * the MMIO written values to update the head pointer. */ >

Hi, This is the first attempt to add a new qemu nvme backend using in-kernel nvme target. Most code are ported from qemu-nvme and also borrow code from Hannes Reinecke's rts-megasas. It's similar as vhost-scsi, but doesn't use virtio. The advantage is guest can run unmodified NVMe driver. So guest can be any OS that has a NVMe driver. The goal is to get as good performance as

Hi, This is the first attempt to add a new qemu nvme backend using in-kernel nvme target. Most code are ported from qemu-nvme and also borrow code from Hannes Reinecke's rts-megasas. It's similar as vhost-scsi, but doesn't use virtio. The advantage is guest can run unmodified NVMe driver. So guest can be any OS that has a NVMe driver. The goal is to get as good performance as

On 20/11/2015 09:11, Ming Lin wrote: > On Thu, 2015-11-19 at 11:37 +0100, Paolo Bonzini wrote: >> >> On 18/11/2015 06:47, Ming Lin wrote: >>> @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) >>> } >>> >>> start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head;

On 20/11/2015 09:11, Ming Lin wrote: > On Thu, 2015-11-19 at 11:37 +0100, Paolo Bonzini wrote: >> >> On 18/11/2015 06:47, Ming Lin wrote: >>> @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) >>> } >>> >>> start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head;

Hi Rob & Mihai, I wrote vhost-nvme patches on top of Christoph's NVMe target. vhost-nvme still uses mmio. So the guest OS can run unmodified NVMe driver. But the tests I have done didn't show competitive performance compared to virtio-blk/virtio-scsi. The bottleneck is in mmio. Your nvme vendor extension patches reduces greatly the number of MMIO writes. So I'd like to push it

Hi Rob & Mihai, I wrote vhost-nvme patches on top of Christoph's NVMe target. vhost-nvme still uses mmio. So the guest OS can run unmodified NVMe driver. But the tests I have done didn't show competitive performance compared to virtio-blk/virtio-scsi. The bottleneck is in mmio. Your nvme vendor extension patches reduces greatly the number of MMIO writes. So I'd like to push it

On 21/11/2015 00:05, Ming Lin wrote: > [ 1.752129] Freeing unused kernel memory: 420K (ffff880001b97000 - ffff880001c00000) > [ 1.986573] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x30e5c9bbf83, max_idle_ns: 440795378954 ns > [ 1.988187] clocksource: Switched to clocksource tsc > [ 3.235423] clocksource: timekeeping watchdog: Marking clocksource 'tsc'

Hello all, I'm relatively new to "R" and programming in general - I had previously used MatLab, but decided to make the transition to R, as the computational times are much better! Anyway, I'm trying to use R to run a gamma distribution model to estimate mean transit times of water moving through a hydrological catchment. My input are 3 .txt format files as follow:

On Sun, Sep 18, 2016 at 12:32 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Sep 17, 2016, at 3:19 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> So, when I embark on the next ThinLTO try build, probably this Sunday, >> should I append -Wl,-plugin-opt,jobs=NUM_PHYS_CORES to LDFLAGS >> and run ninja without -j or

The current behavior is to not specify any toolchain and invoke CMake without additional arguments for configuring the NATIVE portion of the build. However, CMake will actually set the CC, CXX, and FC environment variables to full paths of the compilers in the CMAKE_{C,CXX,Fortran}_COMPILER CMake variables inside the CMake process. This results in those variables being propagated to any

On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote: > On Thu, 11 Apr 2019 14:01:54 +0300 > Yuval Shaia <yuval.shaia at oracle.com> wrote: > > > Data center backends use more and more RDMA or RoCE devices and more and > > more software runs in virtualized environment. > > There is a need for a standard to enable RDMA/RoCE on Virtual Machines. > >

On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote: > On Thu, 11 Apr 2019 14:01:54 +0300 > Yuval Shaia <yuval.shaia at oracle.com> wrote: > > > Data center backends use more and more RDMA or RoCE devices and more and > > more software runs in virtualized environment. > > There is a need for a standard to enable RDMA/RoCE on Virtual Machines. > >

On Tue, Jan 27, 2015 at 10:02 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Adding -D__MSVCRT_VERSION__=0x900 (or higher) to CMAKE_CXX_FLAGS and > -lmsvcr90 (or higher) to CMAKE_CXX_STANDARD_LIBRARIES appears to work. > -lmsvcrt80 does not work, contrary to the comment on the MinGW bug tracker. > However, if you do not