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 52EB2A04F2; Thu, 5 Dec 2019 09:31:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9CE651BF7F; Thu, 5 Dec 2019 09:31:34 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id B5FDF1BF7B 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-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-106-aDcZHjk6NQeMTqaYevPanA-1; Thu, 05 Dec 2019 03:31:30 -0500 Received: by mail-vk1-f199.google.com with SMTP id m25so1168086vko.19 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=UbMzZq2pWJOVmay3mU5nDHPLJDjl911UdwAWij1RchDM9yUlIQ6l1fsw6Z7PTmtOtr BlkGonfcMw9e3TT9P65fN4Xj7+TMIfj6mPlQqBF/PAT4PxDvY48Cx8BA7QkxdBgwx+gi NUf3gGTE/5x3PPvpdNBXuYFErtOBRWPu4SGtC1oXV18IVCTq7xxml+ImfY8wpaXdoRfc c420QJKsovM580gp3n5cePb3GgMy5jHqTJix4Qu6DYD/MydNNQvN9y0ybPLrWp1YnyUU I1GM6Z1qUNR+fvnXqnVi2baPFkgPz61rrJR0BgzydwaZd1dG+ppqrHjnSq2spdCdXBXC uiGQ== X-Gm-Message-State: APjAAAXp9jvkSX66nCbc1oViAOJr6HAsdWfu6DWy9gAXz2NhapOSABv5 ONfa2Pd+ceJE9T26gQIRjWs5phdf98k0uR5rAiwZgxw6Mhj2rEPKUs230tZpmRyvs3/6qb6hMFf /KoF/u0FbgGLKzyzGyx8= X-Received: by 2002:ab0:488b:: with SMTP id x11mr379038uac.86.1575534690259; 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: aDcZHjk6NQeMTqaYevPanA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] test/common: fix log2 check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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