From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 67721A04F2 for ; Thu, 5 Dec 2019 09:31:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 394661BF88; Thu, 5 Dec 2019 09:31:36 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id B9BF01BF7F for ; Thu, 5 Dec 2019 09:31:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575534693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bOMAHn2JVmHAdhHoBoIrfxPOqW79tyZUvPdKDlMwh34=; b=Y8hubgb+vpi3a0ipCp63tZd1BYtQozAlFAepOgU4CZ12K8B6GgDlzxLnxsO2AJ9Ek8TlUt tPJqPKiccQtbxag9MxVfbGBVSwIgIG3ZtJyZgAuL1TlN0PLOhs7zE662LILzHESJNwVxKk 1t4bKXm/jy6eYmiULofnq3wxgsCxDR0= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-355-4i602mVDMOGZ0cz-RToZ8w-1; Thu, 05 Dec 2019 03:31:30 -0500 Received: by mail-vk1-f200.google.com with SMTP id x65so1173792vkd.15 for ; Thu, 05 Dec 2019 00:31:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kUaC8FWMNcsyCHNQ04/cIQUz5g1wv07LI8zYxLaWyFQ=; b=nhJjvY4KzNi2OnscEAEBJpS/2QRrabqIG5A6OxdqJrcjXL2EqEcPDEwa30ZChvmCcf opG+zaZYFOQ1+OyjFXACZiG7JeRDcjZhf/SOErYKLT+es8qe01mpgjlVWxVn7XPO7FLF wv5u1HujU7dRCq/oi031VfIqDUfhXmjzY77yE4BCXPJQ11R9PCagAzkwjI/r0HPIg3jf Gt6JFj6pRpa7/KcOHi3xfLu2qoWEwHWpjOewRfel/BsTIFRid8BtTN7plhpbPUkn+LFB 8uNDiKhXaekC3r2uNOlHpMFVFxkLElYNaq5ohix7IUKKo9G7xNjujl1J/U+edSfJ9YSl jmMg== X-Gm-Message-State: APjAAAVrECquT2JP5w/xA1gdMksEJCvIQYGxS6dQ7HYCi7s9KPGIiJd6 Lbqi+fK36/hsFswzGE9s5KUP+4X0y6PQ/m2dNDUKyh4gX/5tk41Tc2YX3tvxNeYUngLdgjZSnFP 076FYlbnttWWJHK2zMJ/tFrk= X-Received: by 2002:ab0:488b:: with SMTP id x11mr379036uac.86.1575534690258; Thu, 05 Dec 2019 00:31:30 -0800 (PST) X-Google-Smtp-Source: APXvYqwHcK9y6RCf0VBLfrOHC1RRsSskjjlGNNcZ9BeDrX9ZqFFU009JYmb3Ti4ZXLWzzq2SeVZrnZ13vTreUkwZqyI= X-Received: by 2002:ab0:488b:: with SMTP id x11mr379007uac.86.1575534689799; Thu, 05 Dec 2019 00:31:29 -0800 (PST) MIME-Version: 1.0 References: <20191204205241.5691-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Thu, 5 Dec 2019 09:31:18 +0100 Message-ID: To: Aaron Conole Cc: dev , dpdk stable X-MC-Unique: 4i602mVDMOGZ0cz-RToZ8w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [PATCH] test/common: fix log2 check X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Wed, Dec 4, 2019 at 10:20 PM Aaron Conole wrote: > > David Marchand writes: > > > We recently started to get random failures on the common_autotest ut wi= th > > clang on Ubuntu 16.04.6. > > > > Example: https://travis-ci.com/DPDK/dpdk/jobs/263177424 > > > > Wrong rte_log2_u64(0) val 0, expected ffffffff > > Test Failed > > > > The ut passes 0 to log2() to get an expected value. > > > > Quoting log2 / log(3) manual: > > If x is zero, then a pole error occurs, and the functions return > > -HUGE_VAL, -HUGE_VALF, or -HUGE_VALL, respectively. > > > > rte_log2_uXX helpers handle 0 as a special value and return 0. > > Let's have dedicated tests for this case. > > > > Fixes: 05c4345ef5c2 ("test: add unit test for integer log2 function") > > Cc: stable@dpdk.org > > > > Signed-off-by: David Marchand > > --- > > Acked-by: Aaron Conole > > Somethings that concern me: > > 1. A log2(0) should probably be an undetermined value, but this > effectively makes log2(0) =3D=3D log2(1) so that if anyone uses these > for some mathematical work, it will have an exceptional behavior. I > know it's documented from a programmer perspective, but I am all for > documenting the mathematical side effect as well. What do you have in mind, adding a big warning in the doxygen "THIS IS NOT REAL MATH STUFF" ? :-) > > 2. Why hasn't this been complaining for so long? Or has it and we just > haven't noticed? Were some compiler flags changed recently? (maybe > -funsafe-math was always set or something?) Yes, I wondered too how we did not see this earlier. Even now, it happens randomly. libc log2(0) is not undefined itself, it returns -infinity. Looking at the test code, ceilf (I would expect ceil) returns -infinity when getting it passed. So I'd say the problem lies in the cast to uint32_t. Both gcc and clang do not seem to bother with standard compilation flags, and the cast gives 0 on my RHEL. #include #include #include int main(int argc, char *argv[]) { printf("%lf %f %"PRIu32"\n", log2(0), (float)log2(0), (uint32_t)log2(0)= ); return 0; } $ ./log2 -inf -inf 0 Now, if I use UBSAN with clang, I get a complaint at runtime: $ ./log2 (/home/dmarchan/log2+0x41dfa5): runtime error: value -inf is outside the range of representable values of type 'unsigned int' -inf -inf 0 Not sure if it explains the random failures, but won't undefined behavior eat your babies? --=20 David Marchand