[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] iotest 013 failure under clang -fsanitize=undefined
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] iotest 013 failure under clang -fsanitize=undefined |
Date: |
Wed, 03 Feb 2016 08:19:37 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Laszlo Ersek <address@hidden> writes:
> On 02/02/16 21:03, John Snow wrote:
>> Recently, qemu iotest 013 has started to fail for me:
>>
>> Fedora release 22 (Twenty Two)
>>
>> 3.5.0-9.fc22
>> clang version 3.5.0 (tags/RELEASE_350/final)
>> Target: x86_64-redhat-linux-gnu
>> Thread model: posix
>>
>>
>> +4 KiB/home/jsnow/src/qemu/qemu-io-cmds.c:230:18: runtime error:
>> division by zero
>>
>>
>> The problem is that in the print report for read_f, t2 and t1 can
>> actually be the same exact timestamp, and tdiv will try to divide by 0.0.
>>
>> Normally this is not a problem as this is defined to be INFINITY in C99
>> Annex F.
>>
>> Clang, however, has once again decided to take the pedantic road and
>> state that Annex F is optional, and therefore division by 0.0 is
>> actually undefined when using -fsanitize=undefined.
>>
>> Groan.
>>
>> Two workarounds:
>>
>> (1) Modify the tdiv() function to just return INFINITY manually if the
>> timestamp provided is 0
>>
>> (2) Modify tester scripts to also use -fno-sanitize=float-divide-by-zero
>>
>>
>> I prepared a patch to do the first workaround [1] so I could test
>> patches with clang in peace as I need to test my pull requests under
>> clang to make sure I don't break OSX, but it seems so absurd to have to
>> do this, so I have copied our resident language lawyers (and language
>> pragmatists) so that they can have a say.
>>
>> Relevant upstream BZ: https://llvm.org/bugs/show_bug.cgi?id=17000
>>
>> --js
>>
>> [1]
>> https://github.com/jnsnow/qemu/commit/af93977dd2bc7ea936b8064c41c5a0f9d25ae2d1
>>
>
> Apologies in advance for the knee-jerk reaction:
>
> I don't use double, ever. The last time I did anything resembling
> numerical analysis was in college (now gracefully veiled by time).
>
> If I need decimals after the point, I opt for fixed point math, done
> with integers. Surely uint64_t suffices for the purposes of
> "qemu-io-cmds.c"; it just forces the programmer to think about those
> issues explicitly that "double" promises, but fails, to solve.
I doubt integer types can "force" someone who uses double unthinkingly
not to use uint64_t equally unthinkingly. People who manage to misuse
floating-point for trivial computations like "given an amount and a
time, compute rate per second" are likely to misuse integers as well.
With integers, they get a crash when computing a rate for a time that
got flushed to zero, which has a chance to do some forcing after the
fact (whatever good that may do). With double, they get an infinity,
which has a real chance to just work (it does in qemu-io).
> I doubt microsecond resolution is necessary here, but even if it is, I'd
> assume that approx. 584,942 years sufficed as an upper limit on time
> differences.
>
> To frobnicate the saying about regular expressions, "when people want to
> print decimals, they reach for floating point -- now they have two
> problems".
Fixed point has its own set of problems. Sometimes they're preferrable
to floating-point problems, sometimes they aren't.