4 files changed, 187 insertions, 0 deletions
diff --git a/results/classifier/108/other/1655 b/results/classifier/108/other/1655
new file mode 100644
index 00000000..c210853d
--- /dev/null
+++ b/results/classifier/108/other/1655
@@ -0,0 +1,16 @@
+device: 0.851
+network: 0.727
+vnc: 0.678
+performance: 0.650
+socket: 0.581
+files: 0.556
+graphic: 0.514
+semantic: 0.440
+permissions: 0.435
+debug: 0.379
+PID: 0.371
+boot: 0.316
+other: 0.148
+KVM: 0.124
+
+qemu-7.2.2 build failed
diff --git a/results/classifier/108/other/1655700 b/results/classifier/108/other/1655700
new file mode 100644
index 00000000..54f64f81
--- /dev/null
+++ b/results/classifier/108/other/1655700
@@ -0,0 +1,46 @@
+other: 0.749
+graphic: 0.726
+device: 0.571
+performance: 0.569
+vnc: 0.537
+PID: 0.416
+socket: 0.411
+files: 0.403
+network: 0.378
+semantic: 0.311
+KVM: 0.286
+permissions: 0.208
+boot: 0.188
+debug: 0.174
+
+disas/libvixl/vixl/invalset.h: possible dodgy code in binary search ?
+
+
+[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check.
+
+Source code is
+
+    while (!IsValid(elements[low]) && (low < high)) ++low;
+
+Also:
+
+qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check.
+
+The source code is
+
+   while (!IsValid(elements[high]) && (low < high)) --high;
+
+Mind you, these lines of code look similar but didn't get reported:
+
+    while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle;
+    while (!IsValid(elements[middle]) && (low + 1 < middle)) --middle;
+
+Given that binary search is notoriously tricky to get correct and a standard C library routine
+I am puzzled as to why the standard library routine didn't get used, with of course a custom
+comparison function.
+
+That doesn't look like a bounds check to me, so I think your checker is producing false positives.
+
+libvixl is third-party code in any case, so stylistic questions are better directed to them upstream. But I think the difference between this code and a standard binary search is (as the comment says) that it ignores invalid elements in the array.
+
+
diff --git a/results/classifier/108/other/1655708 b/results/classifier/108/other/1655708
new file mode 100644
index 00000000..882762c0
--- /dev/null
+++ b/results/classifier/108/other/1655708
@@ -0,0 +1,82 @@
+other: 0.855
+device: 0.812
+semantic: 0.811
+socket: 0.783
+PID: 0.745
+vnc: 0.741
+graphic: 0.661
+performance: 0.660
+boot: 0.654
+network: 0.587
+permissions: 0.583
+files: 0.555
+KVM: 0.520
+debug: 0.473
+
+target/ppc/int_helper.c:2806: strange expression ?
+
+target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
+
+Source code is
+
+       zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 : zone_lead;
+
+Which I read as
+
+       zone_digit = (i * 2) ? (b->u8[BCD_DIG_BYTE(i * 2)] >> 4) : zone_lead;
+
+so I think the compiler warning is for the i * 2 lhs of the ?.
+
+I am not sure what to suggest as a bugfix.
+
+On 01/11/2017 10:41 AM, dcb wrote:
+> Public bug reported:
+> 
+> target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context,
+> suggest ‘&&’ instead [-Wint-in-bool-context]
+> 
+> Source code is
+> 
+>        zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 :
+> zone_lead;
+
+Also, looking at BCD_DIG_BYTE():
+
+#if defined(HOST_WORDS_BIGENDIAN)
+#define BCD_DIG_BYTE(n) (15 - (n/2))
+#else
+#define BCD_DIG_BYTE(n) (n/2)
+#endif
+
+Oops. n is under-parenthesized, and will cause invalid expansions for
+some expressions.  Let's fix that as well.
+
+
+> so I think the compiler warning is for the i * 2 lhs of the ?.
+
+Yes - the compiler is complaining that 'i * 2' can only be non-zero if
+'i' was non-zero (given that the code occurs in a loop for i between 0
+and 16), so it is just as easy to write 'i ? ...' instead of the weirder
+'(i * 2) ? ...'.
+
+-- 
+Eric Blake   eblake redhat com    +1-919-301-3266
+Libvirt virtualization library http://libvirt.org
+
+
+
+> so it is just as easy to write 'i ? ...' instead of the weirder
+> '(i * 2) ? ...'.
+
+I suspect it is just possible that the i * 2 expression is a typo
+for something else, perhaps i & 2 or i << 2 or i >> 2 or something else.
+
+I don't know the code so I am unable to offer better guidance.
+ 
+
+Patch has been posted to the mailing list:
+https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02008.html
+
+Fix had been committed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=365206aeb3d0bb72043d
+
diff --git a/results/classifier/108/other/1655764 b/results/classifier/108/other/1655764
new file mode 100644
index 00000000..009e151d
--- /dev/null
+++ b/results/classifier/108/other/1655764
@@ -0,0 +1,43 @@
+other: 0.877
+graphic: 0.825
+device: 0.814
+semantic: 0.800
+performance: 0.766
+files: 0.705
+socket: 0.692
+vnc: 0.691
+permissions: 0.680
+boot: 0.662
+network: 0.656
+PID: 0.615
+debug: 0.474
+KVM: 0.417
+
+qemu-img convert -c compression can't decompress
+
+Used -c compression option of qemu-img convert to compress qcow2,
+then libvirt mount for compressed image don't work as well as decompression also
+not working, tried glib-deflate to decompress
+
+Used openssl zlib -d < compressedfile but that also not working
+
+When tried zlib-flate -uncompress < cirros-0.3.4-x86_64-disk.img,
+getting below error
+
+data: incorrect header check
+
+Which version of QEMU (or rather qemu-img) are you using?
+
+qemu-img version 2.1.2, Copyright (c) 2004-2008 Fabrice Bellard
+
+When reporting bugs, please always use the latest version of QEMU, old versions like 2.1 are not supported anymore. I just also noticed that Stefan Hajnoczi replied to the bug mail on the qemu-devel mailing list (see https://<email address hidden>/msg422186.html) - seems like the bridge did not mirror this to the bug tracker:
+
+"QEMU image compression uses the compression feature available in some
+ disk image formats (like qcow2).  This is not the same as compressing a
+ file with gzip, bzip2, or similar tools.
+ Therefore this error is expected and not a bug."
+
+Yes used qcow2 format only when compressing, I don't think due to older version problem
+
+When converting qcow2 with -c option, then after not able to boot VM with compressed qcow2 image
+