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 0BC71A04F2; Thu, 5 Dec 2019 15:39:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0046D1BF81; Thu, 5 Dec 2019 15:39:31 +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 7139C1BF7B for ; Thu, 5 Dec 2019 15:39:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575556769; 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=0SSX19Xweo74FdfwxgH4Pjo0VdsOHqtPhuk6QO5Vix0=; b=hG0wWhG5jMItoz02nffk6kG8b9i1lpLAPub89AdQYMPSVksTUG5ecsNeKghVjiIyyAmj+f vFFfxvDJUGrhsd3Kns4XO8TvJthqFqWwpqwX9xf6T3bC8/YvKMwO/I7gCE9eHrJN5fY5+h Dufjp1rLo4Yp5CUJacLMSuo+lgMVhEc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-tUcHpJUhOl-j9tbKZ9-liA-1; Thu, 05 Dec 2019 09:39:27 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D58588EDBD0; Thu, 5 Dec 2019 14:39:26 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-124-234.rdu2.redhat.com [10.10.124.234]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5739B19756; Thu, 5 Dec 2019 14:39:26 +0000 (UTC) From: Aaron Conole To: David Marchand Cc: dev , dpdk stable References: <20191204205241.5691-1-david.marchand@redhat.com> Date: Thu, 05 Dec 2019 09:39:25 -0500 In-Reply-To: (David Marchand's message of "Thu, 5 Dec 2019 09:31:18 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: tUcHpJUhOl-j9tbKZ9-liA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain 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" David Marchand writes: > 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 w= ith >> > 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 thes= e >> 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" ? :-) Is such a warning not reasonable? :-) >> >> 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? Possibly. I would still expect it to be consistent when it eats babies, but maybe it doesn't have to be.