similar to: double to unsigned char cast

Hi Jay, On 5 April 2018 at 07:49, Jay K via llvm-dev <llvm-dev at lists.llvm.org> wrote: > wrt > https://github.com/mono/mono/commit/fb91fce5d339bb9ffe507588f5bc1d8d6f244d9b > > > This doesn't seem right to me. Nevertheless, it's what the standard says. C99 6.3.1.4: When a finite value of real floating type is converted to an integer type other than _Bool, the

This seems disappointing. Casting any value to an integral type should yield a value within the range of that integral type. The value can be anything, but it should be within range. i.e. it should be as if I anded it with (type)~(type)0. i.e. int i = (signed char)x; assert(i >= -128 && i <= 127); int i = (unsigned char)x; assert(i >= 0 && i <= 255); seem very

I'd also note that -fsanitize=undefined will detect the error at runtime. On Fri, May 25, 2018 at 4:38 AM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, May 22, 2018 at 6:17 PM, Jay K via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > This seems disappointing. > > > > Casting any value to an integral type should yield a value

On Tue, May 22, 2018 at 6:17 PM, Jay K via llvm-dev <llvm-dev at lists.llvm.org> wrote: > This seems disappointing. > > Casting any value to an integral type should yield a value within the range > of that integral type. As Tim pointed out, that's not what the standard says though. Trunk Clang (I'm not sure what version your Xcode Clang is based on) has a flag to

I find it surprising that given this: void f1() { const struct { int a; } b = { 0 }; } that clang does not put b on the stack. gcc does. My gut feeling says it belongs on stack. But perhaps, the thing is, it is const, and location shouldn't matter to most code, as long as lifetime is adequate. Almost no code could tell the difference. But we have code that takes the address of things, and

Our replacements for these functions are not undefined for negative values. Thanks: Eric Blake Fixes: commit 9f34db74786fdc92b290a7d47e4b003bd84fec69. --- plugins/sh/call.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/plugins/sh/call.c b/plugins/sh/call.c index b2d4a794..741022b6 100644 --- a/plugins/sh/call.c +++ b/plugins/sh/call.c @@ -443,7 +443,7 @@

Some virtio-win drivers contain more files than just *.{cat,inf,sys}. They are filtered out currently, which prevents the drivers from being installed by PnP. Stop filtering driver files by extension, and copy all of them instead. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v1 -> v2: - update unit test to match the changed behavior v2v/v2v_unit_tests.ml | 202

Instead of trying to split and parse elements from virtio-win paths, use the '*.inf' files supplied with the drivers to control how Windows drivers are installed. The following emails best explain how this works: https://www.redhat.com/archives/libguestfs/2015-October/msg00352.html https://www.redhat.com/archives/libguestfs/2015-November/msg00065.html Currently the product variant (eg.

On Tue, 2015-11-17 at 19:44 +0000, Richard W.M. Jones wrote: > I think one - maybe final? - problem. How can I tell the difference > between drivers for "client" versions of Windows (eg. Windows 7) > and server versions of Windows (eg. Windows 2008 Server)? > > It seems in many or most cases the drivers are identical, eg: > > $ md5sum viostor/2k12/amd64/*

> > I didn't realize the code was undefined, I'll let my professor know; but > for code comparison purposes we're still seeking advice on producing the > output that matches the other compilers (even if it involves doing a > translation on the .ll file or additional translation to the produced > assembly). We can't fairly compare the code if it doesn't do the

I think one - maybe final? - problem. How can I tell the difference between drivers for "client" versions of Windows (eg. Windows 7) and server versions of Windows (eg. Windows 2008 Server)? It seems in many or most cases the drivers are identical, eg: $ md5sum viostor/2k12/amd64/* viostor/w8/amd64/* bbe250c13bf891fd7292ccab9908a63a viostor/2k12/amd64/viostor.cat

----- Original Message ----- > From: "Amnon Ilan" <ailan@redhat.com> > To: "Vadim Rozenfeld" <vrozenfe@redhat.com>, "Li Jin" <lijin@redhat.com> > Cc: "Richard W.M. Jones" <rjones@redhat.com>, "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Jeff > Nelson" <jenelson@redhat.com>,

I dual boot w8 and Arch Linux. Both are on the same ssd drive (each OS have of course a partition). Now I would like to virtualize w8 and run it inside Arch Linux using KVM/QEMU and Libvirt. w8 has already been installed on a ntfs partition. As it is brand new, it will not be difficult to reinstall it on a image.raw I have been reading some articles and found myself a little bit confused. 1-

+Li Jin ----- Original Message ----- > From: "Vadim Rozenfeld" <vrozenfe@redhat.com> > To: "Richard W.M. Jones" <rjones@redhat.com> > Cc: "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Amnon Ilan" <ailan@redhat.com>, "Jeff Nelson" > <jenelson@redhat.com>, "Yan Vugenfirer"

I am using this command to install a w8 guest on my Archlinux host: virt-install --connect qemu:///system --name=tintinVM --ram 4096 --cpu host-model-only --os-variant=win7 --disk /dev/vg0/tintin,size=120,bus=virtio,sparse=false,format=raw --name="tintinVM" --network bridge=virbr0,model=virtio --graphics spice --cdrom /dev/cdrom The virtual machine window open and show the blue windows

I plan to dual boot w8 and Archlinux, and virtualize the same w8 machine with libvirt qemu/kvm. I already did the dual boot. I am now starting the virtualization. My plan was to use the w8 partition as a Disk volume pool [1]. Unfortunately, I didn't noticed only FAT32 was a valid format when I installed w8 on NTFS. I need to change my whole setup, but beforethat, I want to be sure libvirt

I've been trying to build R 3.3.1 inside of a Nix environment on a Ubuntu 16.04 machine. It builds, but then it fails a regression test related to time zones, and I hope that someone could help me debug the problem. The failing test is in tests/reg-tests-rc.R (https://github.com/wch/r-source/blob/c3fe9cd4/tests/reg-tests-1c.R#L1577-L1587): ## format.POSIXlt() of Jan.1 if 1941 or '42 is

I am compiling the following code for the MIPS architecture: unsigned char trunc(float f) { return (unsigned char) f; } and it produces the following assembly (directives removed for convenience: trunc: trunc.w.s $f0, $f12 mfc1 $2, $f0 jr $ra nop However, this does not seem to produce the correct output for negative numbers. When I run the following code, I get

AArch64AddressTypePromotion.cpp does a fair bit of work to help make these things work out well. It could probably be generalized for non-AArch64 targets as per the comment in the file header. > On Jun 26, 2014, at 10:42 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > Cool HW trick. :) > Are those 'sxtw' ops free? > That’ll depend on the details of the

Currently the AtomicExpandPass will lower the following IR: define i1 @foo(i32* %obj, i32 %old, i32 %new) { entry: %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new _*release acquire*_ %v1 = extractvalue { i32, i1 } %v0, 1 ret i1 %v1 } to the equivalent of the following on AArch64: _*ldxr w8, [x0]*_ cmp w8, w1 b.ne .LBB0_3 // BB#1: