[PATCH v0 0/2] Add C23 stdbit.h functions

[Joel Sherrill]

On Tue, Mar 17, 2026 at 12:35 PM Corinna Vinschen <corinna@vinschen.de>
wrote:

> Hi Joel,
>
> On Mar 13 12:03, Joel Sherrill wrote:
> > This patch series is a draft and feedback is appreciated on what
> > is required to run "autoreconf" to get build infrastructure that
> > does not give an error. See
> > https://sourceware.org/pipermail/newlib/2026/022334.html for
> > details on the make error.
> >
> > Once this builds, I can foresee at least one more problem.
> > The header file stdbit.h does not have C23 guards and neither
> > do any of the implementation files. If these function files
> > are to be compiled by an older compiler without C23 support,
> > they should be disabled. At this point, I see adding a C23
> > guard to stdbit.c and stdbit/*.c files.
>
> Actually, no.
>

OK. That makes it easier.

>
> - The fact that these functions are only required by a C23 environment
>   doesn't mean that an older compiler shouldn't be able to build them.
>   They should be buildable and built, as long as the compiler provides
>   the matching builtins.
>
> - The header doesn't offically exist prior to C23.  So if a source file
>   includes this file, it's building for C23 or later by default.
>   There's no guard required.  It's different *only* for the compiler
>   building newlib itself, but this compiler should have access to the
>   header.
>
> The problem with stdbit/Makefile.inc is that you used %D instead of %D%.
> This breaks the generated Makefile.
>

Thanks. and Grrrr.. one character mistakes can be so hard to spot. :(

>
> With that fixed, your code still doesn't build (with gcc 13.4.0,
> cross-building for Cygwin), because the compiler complains about missing
> definitions for UINT_WIDTH, ULLONG_WIDTH, etc.  Maybe you should use
> __LONG_WIDTH__ etc.?
>

That code is unmodified from FreeBSD.  Once I get this far, I can address
that.

Right now, after autoreconf, I see this error:

I see this pattern with git diff which looks wrong. Lots of lines in
Makefile.in
where the libm_ part disappeared after "common/"

-libm/common/libm_a-sf_fpclassify.$(OBJEXT):  \
-       libm/common/$(am__dirstamp) \
+libm/common/a-sf_fpclassify.$(OBJEXT): libm/common/$(am__dirstamp) \

And missing the libc_ part after "argz"

-@ELIX_LEVEL_1_FALSE@   libc/argz/libc_a-envz_strip.$(OBJEXT)
+@ELIX_LEVEL_1_FALSE@am__objects_1 = libc/argz/a-argz_add.$(OBJEXT) \

I do not see any modified files that would do this.

I have run autoreconf with Rocky 9 autotools and locally built unmodified
versions.

autoconf (GNU Autoconf) 2.69
automake (GNU automake) 1.16.5

Sorry to be a problem. I just do not seem to be able to regenerate a
working Makefile.in

Help appreciated.

--joel



>
> Thanks,
> Corinna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20260317/8f658a6b/attachment.htm>