GNU bug report logs - #70898
switching to <stdbit.h> for Emacs bit ops

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70898 in the body.
You can then email your comments to 70898 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Subject: switching to <stdbit.h> for Emacs bit ops
Date: Sun, 12 May 2024 15:09:17 -0700

[Message part 1 (text/plain, inline)]

Emacs currently uses the Gnulib headers count-trailing-zeros.h and 
count-one-bits.h to do some low-level bit operations efficiently. C23 
has standardized this in a new header <stdbit.h> and I've recently added 
support for a Gnulib <stdbit.h> substitute, taking implementation ideas 
from count-trailing-zeros.h, count-one-bits.h and elsewhere. So I'm 
planning to switch Emacs to the C23 standard way of doing things, using 
the Gnulib substitute on non-C23 platforms.

The first attached patch does this. I plan to test this somewhat more 
before installing, but thought I'd give people a heads-up.

The second attached patch is a minor cleanup to the 32-bit Android code, 
a cleanup made possible by the first attached patch. This cleanup patch 
is optional of course. By the way, I'm surprised to see the code in 
sfmt.c implementing 64-bit arithmetic from pairs of 32-bit words, as I 
thought even ancient 32-bit Android has 64-bit 'unsigned long long', but 
that's a matter for the Android experts I suppose.

[0001-Prefer-stdbit.h-to-count-one-bits.h-etc.patch (text/x-patch, attachment)]

[0002-Simplify-32-bit-Android-bit-fiddling.patch (text/x-patch, attachment)]

Message #8 received at 70898 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 70898 <at> debbugs.gnu.org
Subject: bug#70898: switching to <stdbit.h> for Emacs bit ops
Date: Mon, 13 May 2024 16:34:48 +0200

Has C23 been frozen yet? The most recent accessible draft I could find was N3096.

Overall happy with the changes but haven't read them in detail.
Minor things I stumbled upon:

> @@ -4269,7 +4263,9 @@ endif
>  ## begin gnulib module verify
>  ifeq (,$(OMIT_GNULIB_MODULE_verify))
>  
> +ifneq (,$(gl_GNULIB_ENABLED_verify_CONDITION))
>  
> +endif

Unfinished work?

> +/* 1 if supported, -1 if not, 0 if unknown.  */
> +extern signed char __gl_stdint_popcount_support;

`__gl_stdbit_popcount_support`, maybe?


(By the way, in case you are on the WG: the N3096 draft has

> 7.18.8 First Leading One
...
> Returns the most significant index of the first 1 bit in value, plus 1.

Someone jumbled that sentence. Something like "the index of the most significant 1 bit" was probably intended.

Message #11 received at 70898 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70898 <at> debbugs.gnu.org
Subject: Re: bug#70898: switching to <stdbit.h> for Emacs bit ops
Date: Mon, 13 May 2024 09:56:46 -0700

On 2024-05-13 07:34, Mattias Engdegård wrote:
> Has C23 been frozen yet? The most recent accessible draft I could find was N3096.

It's not final, but it's pretty frozen. I doubt whether the stdbit spec 
will change.

Yes, n3096 is the latest public draft.


> Overall happy with the changes but haven't read them in detail.
> Minor things I stumbled upon:
> 
>> @@ -4269,7 +4263,9 @@ endif
>>   ## begin gnulib module verify
>>   ifeq (,$(OMIT_GNULIB_MODULE_verify))
>>   
>> +ifneq (,$(gl_GNULIB_ENABLED_verify_CONDITION))
>>   
>> +endif
> 
> Unfinished work?

That was generated automatically by gnulib-tool and is harmless. That 
being said, I installed a change to the Gnulib stdbit module for other 
reasons (porting to theoretical platforms where C integers are wider 
than 256 bits!) here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9768940fbd11558b8dab3453aa419a3433933d50

and I expect that will remove the harmless code by removing the 
conditional dependency on Gnulib's assert-h module.


>> +/* 1 if supported, -1 if not, 0 if unknown.  */
>> +extern signed char __gl_stdint_popcount_support;
> 
> `__gl_stdbit_popcount_support`, maybe?

Thanks, fixed here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9deb8e8891e36968deeb93bd666670f7950d1095


> (By the way, in case you are on the WG: the N3096 draft has

Yes, that text is weird and I also didn't have a clue as to what it 
meant. So I cloned latest glibc+gcc behavior and hoped for the best.

I have avoided dealing with that WG for decades as my political skills, 
such as they are, are better deployed elsewhere. But you're welcome to 
file a bug report.

Message #14 received at 70898 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 70898 <at> debbugs.gnu.org
Subject: Re: bug#70898: switching to <stdbit.h> for Emacs bit ops
Date: Tue, 14 May 2024 13:11:53 +0200

13 maj 2024 kl. 18.56 skrev Paul Eggert <eggert <at> cs.ucla.edu>:

> (porting to theoretical platforms where C integers are wider than 256 bits!)

Impressive! Now all we need is a run-time parametrisable C compiler that can use arbitrary integer sizes, so that your work can be tested.
(Actually that would be incredibly useful for portability work, if only.)

> Yes, that text is weird and I also didn't have a clue as to what it meant. So I cloned latest glibc+gcc behavior and hoped for the best.

Indeed I misunderstood the text and the stdc_find_{first,last} functions look pretty useless. Good to know.

Message #17 received at 70898 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 70898 <at> debbugs.gnu.org
Subject: Re: bug#70898: switching to <stdbit.h> for Emacs bit ops
Date: Sat, 18 May 2024 10:32:10 -0700

I installed an updated version of the patch (updated because Gnulib 
mutated) and am closing the bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.