On 01/02/2019 11:27 AM, Gustavo Romero wrote:
Hello Michael, On 12/31/2018 02:50 PM, Michael Crusoe wrote:În lun., 31 dec. 2018 la 06:42, Gustavo Romero <gromero@linux.vnet.ibm.com <mailto:gromero@linux.vnet.ibm.com>> a scris: diff --git a/sam.c b/sam.c index aa94776..23233a0 100644 --- a/sam.c +++ b/sam.c @@ -1408,7 +1408,7 @@ int sam_parse1(kstring_t *s, bam_hdr_t *h, bam1_t *b) else if (type == 'S') while (q + 1 < p) { u16_to_le(strtoul(q + 1, &q, 0), (uint8_t *) str.s + str.l); str.l += 2; _skip_to_comma(q, p); } else if (type == 'i') while (q + 1 < p) { i32_to_le(strtol(q + 1, &q, 0), (uint8_t *) str.s + str.l); str.l += 4; _skip_to_comma(q, p); } else if (type == 'I') while (q + 1 < p) { u32_to_le(strtoul(q + 1, &q, 0), (uint8_t *) str.s + str.l); str.l += 4; _skip_to_comma(q, p); } - else if (type == 'f') while (q + 1 < p) { float_to_le(strtod(q + 1, &q), (uint8_t *) str.s + str.l); str.l += 4; _skip_to_comma(q, p); } + else if (type == 'f') while (q + 1 < p) { float_to_le(strtof(q + 1, &q), (uint8_t *) str.s + str.l); str.l += 4; _skip_to_comma(q, p); } else _parse_err_param(1, "unrecognized type B:%c", type); #undef _skip_to_comma Applying this patch and compiling under a qemu-based sid-ppc64el builder gets us to only a single test failure (yay!) === test_vcf_various: /build/htslib-1.9/htsfile -c /build/htslib-1.9/test/formatcols.vcf The outputs differ: /build/htslib-1.9/test/formatcols.vcf /build/htslib-1.9/test/formatcols.vcf.new .. failed ... ===Thanks for testing it! hmm right... I'm not able to reproduce that failure on my setup. Could you share the differences when it fails? I think a 'diff -u formatcols.vcf formatcols.vcf.new' suffices.
I'm really not able to get any failure with the fix above applied. I've tried with the latest sid/unstable updates, with both -O2 and -O3, on a VM, not baremetal. As a reference, I have: binutils 2.31.1-11 gcc-8 8.2.0-13 libc6-dev:ppc64el 2.28-4 libstdc++-8-dev:ppc64el 8.2.0-13 libstdc++6:ppc64el 8.2.0-13 linux-libc-dev:ppc64el 4.19.13-1 Any chance there was stale file in the builder? If you are able to grab the diff I can investigate it. I'm a bit worried about leaving -O0 for PPC64... Thanks. Cheers, Gustavo
In the meantime, to unclog a chain of packages that have been held back from migrating to testing, I've uploaded a version of the package that uses -O0 for ppc64el only; which I agree is not ideal. If you think this is a qemu-only test failure then I can upload a build to experimental so that real hardware is used (I don't have porter box access)I don't know... but all debugging / testing at my side is on a ppc64el VM (qemu/kvm-only so), so probably not a VM vs baremetal issue. Did you check if the same error happens on x86_64 when that patch is applied? Or it's still ppc64el-specific? Cheers, GustavoCheers, Gustavo > Cheers, > > Steffen > > On 27.12.18 15:41, Michael Crusoe wrote: >> https://buildd.debian.org/status/fetch.php?pkg=htslib&arch=ppc64el&ver=1.9-7&stamp=1545236716&raw=0 >> >> Can I get some assistance here? Rebuilding using Qemu and the earlier source packages produces the same error, so maybe this is a regression in the compiler? >> >> -- >> Michael R. Crusoe >> Co-founder & Lead, Common Workflow Language project <http://www.commonwl.org/> >> Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania >> https://orcid.org/0000-0002-2961-9670 <https://impactstory.org/u/0000-0002-2961-9670> >> mrc@commonwl.org <mailto:mrc@commonwl.org> <mailto:mrc@commonwl.org <mailto:mrc@commonwl.org>> >> +1 480 627 9108 / +370 653 11125 > -- Michael R. Crusoe Co-founder & Lead, Common Workflow Language project <http://www.commonwl.org/> Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania https://orcid.org/0000-0002-2961-9670 <https://impactstory.org/u/0000-0002-2961-9670> mrc@commonwl.org <mailto:mrc@commonwl.org> +1 480 627 9108 / +370 653 11125