qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/28] Misc changes for 2016-02-08


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PULL 00/28] Misc changes for 2016-02-08
Date: Tue, 9 Feb 2016 12:10:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0


On 09/02/2016 10:21, Peter Maydell wrote:
> On 8 February 2016 at 17:02, Paolo Bonzini <address@hidden> wrote:
>> The following changes since commit e4a096b1cd4350eeca5dcdc391ab333d2083d7fd:
>>
>>   ui/cocoa.m: Include qemu/osdep.h (2016-02-08 13:14:40 +0000)
>>
>> are available in the git repository at:
>>
>>   git://github.com/bonzini/qemu.git tags/for-upstream
>>
>> for you to fetch changes up to c3fb8ac5f6d315cf7aecdd1601c27d134c7cdbf5:
>>
>>   ipmi_bmc_sim: Add break to correct watchdog NMI check (2016-02-08 17:36:49 
>> +0100)
>>
>> ----------------------------------------------------------------
>> * switch to C11 atomics (Alex)
>> * Coverity fixes for IPMI (Corey)
>> * at long last, fail on wrong .pc files if -m32 is in use (Daniel)
>> * qemu-char regression fix (Daniel)
>> * SAS1068 device (Paolo)
>> * target-i386 cleanups (Richard)
>> * qemu-nbd docs improvements (Sitsofe)
>> * thread-safe memory hotplug (Stefan)
>>
> 
> Hi; I'm afraid there are some compile issues here:
> 
> On 64-bit ARM and 64-bit PPC:
> 
> /home/pm215/qemu/hw/scsi/mptconfig.c: In function ‘vfill.isra.1’:
> /home/pm215/qemu/hw/scsi/mptconfig.c:86:41: error: ‘val.str’ may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
>                  stl_le_p(data + ofs, val.ll);
>                                          ^

Compiler issue, but easily shut up.

> And a runtime error from the clang undefined behaviour
> sanitizer:
> 
> /home/petmay01/linaro/qemu-for-merges/exec.c:1546:48: runtime error:
> member access within null pointer of type 'DirtyMemoryBlocks'
> 
> which seems to fire for every test in the check-qtest-$ARCH
> tests.

This is almost genuine, :) it's a zero-size memcpy.

clang 1, GCC 1.  Can't complain too loudly this time.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]