From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22689: [PATCH] Add logcount Date: Sat, 30 Sep 2017 16:59:47 +0300 Message-ID: <83a81c478s.fsf@gnu.org> References: <87h9h9pnof.fsf@udel.edu> <20170929174134.e6uxcr63dtyvd6f4@logos.localdomain> <83mv5c4dl0.fsf@gnu.org> <20170930131636.xe22lbwlea7yqelh@logos.localdomain> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1506780076 10254 195.159.176.226 (30 Sep 2017 14:01:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Sep 2017 14:01:16 +0000 (UTC) Cc: 22689@debbugs.gnu.org To: Mark Oteiza Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 30 16:01:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyIKE-0001bq-Ci for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Sep 2017 16:01:02 +0200 Original-Received: from localhost ([::1]:39421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyIKL-0006x6-RI for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Sep 2017 10:01:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyIKH-0006wz-6a for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 10:01:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyIKE-0001eu-0Q for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 10:01:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60778) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dyIKD-0001ef-So for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 10:01:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dyIKD-0004J6-Kg for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 10:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Sep 2017 14:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22689 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22689-submit@debbugs.gnu.org id=B22689.150678000316432 (code B ref 22689); Sat, 30 Sep 2017 14:01:01 +0000 Original-Received: (at 22689) by debbugs.gnu.org; 30 Sep 2017 14:00:03 +0000 Original-Received: from localhost ([127.0.0.1]:41226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyIJH-0004Gx-2v for submit@debbugs.gnu.org; Sat, 30 Sep 2017 10:00:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyIJF-0004Fx-0Y for 22689@debbugs.gnu.org; Sat, 30 Sep 2017 10:00:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyIJ6-0000a8-LM for 22689@debbugs.gnu.org; Sat, 30 Sep 2017 09:59:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyIJ6-0000Zt-Is; Sat, 30 Sep 2017 09:59:52 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3326 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dyIJ5-0005wq-PE; Sat, 30 Sep 2017 09:59:52 -0400 In-reply-to: <20170930131636.xe22lbwlea7yqelh@logos.localdomain> (message from Mark Oteiza on Sat, 30 Sep 2017 09:16:36 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137684 Archived-At: > Date: Sat, 30 Sep 2017 09:16:36 -0400 > From: Mark Oteiza > Cc: 22689@debbugs.gnu.org > > On 30/09/17 at 02:42pm, Eli Zaretskii wrote: > > > +#if defined (__POPCNT__) && defined (__GNUC__) && (__GNUC__> 4 || (__GNUC__== 4 && __GNUC_MINOR__> 1)) > > > +#define HAVE_BUILTIN_POPCOUNTLL > > > +#endif > > > > Where does __POPCNT__ definition come from? I don't see it in my > > GCC's "gcc -dM" output. > > > > As for the rest of the condition, I think you should use GNUC_PREREQ, > > like this: > > > > #if GNUC_PREREQ (4, 1, 0) > > I guess it comes from nowhere, that condition and the two helper > functions come from here > https://rosettacode.org/wiki/Population_count#C I only see that symbol in the GCC sources, which I don't think are relevant here. If you drop the __POPCNT__ part, does the code still work for you? > > > +static uint64_t > > > +bitcount64 (uint64_t b) > > > +{ > > > + b -= (b >> 1) & 0x5555555555555555; > > > + b = (b & 0x3333333333333333) + ((b >> 2) & 0x3333333333333333); > > > + b = (b + (b >> 4)) & 0x0f0f0f0f0f0f0f0f; > > > + return (b * 0x0101010101010101) >> 56; > > > > Shouldn't these constants have a ULL suffix, to make sure they are not > > truncated to a 32-bit int? > > Probably, I don't know--I'm out of my comfort zone here. I'd use the suffixes. > > > +#else /* HAVE_BUILTIN_POPCOUNTLL */ > > > + if (XINT (value) <= UINT_MAX) > > > + XSETINT (res, bitcount32 (XUINT (value))); > > > + else if (XINT (value) <= ULONG_MAX) > > > + XSETINT (res, bitcount64 (XUINT (value))); > > > > The comparisons against Uxxx_MAX seem to assume that VALUE is > > unsigned, but that's not guaranteed, right? > > True. Should I instead be doing > > XINT (value) <= xxx_MAX && > XINT (value) >= xxx_MIN > > or might there be a better check? For negative values popcount > typically counts ones of the two's complement I'd just assign to an unsigned temporary, IIUC the semantics. Btw, on Windows, a long is a 32-bit type, so I think we need to check against ULONG_LONG_MAX as well.