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

  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.

But the first problem is getting it to build at all.

Help appreciated.

Joel Sherrill (2):
  newlib/libc: Add C23 stdbit.h from FreeBSD
  Makefile.inc, stdbit/Makefile.inc: Add stdbit

 newlib/libc/Makefile.inc                      |   1 +
 newlib/libc/include/stdbit.h                  | 124 ++++++++++++++++++
 newlib/libc/stdbit/Makefile.inc               |  15 +++
 newlib/libc/stdbit/stdc_bit_ceil.3            |  81 ++++++++++++
 newlib/libc/stdbit/stdc_bit_ceil.c            |  71 ++++++++++
 newlib/libc/stdbit/stdc_bit_floor.3           |  83 ++++++++++++
 newlib/libc/stdbit/stdc_bit_floor.c           |  53 ++++++++
 newlib/libc/stdbit/stdc_bit_width.3           | 104 +++++++++++++++
 newlib/libc/stdbit/stdc_bit_width.c           |  53 ++++++++
 newlib/libc/stdbit/stdc_count_ones.3          |  85 ++++++++++++
 newlib/libc/stdbit/stdc_count_ones.c          |  38 ++++++
 newlib/libc/stdbit/stdc_count_zeros.3         |  84 ++++++++++++
 newlib/libc/stdbit/stdc_count_zeros.c         |  38 ++++++
 newlib/libc/stdbit/stdc_first_leading_one.3   |  93 +++++++++++++
 newlib/libc/stdbit/stdc_first_leading_one.c   |  57 ++++++++
 newlib/libc/stdbit/stdc_first_leading_zero.3  |  92 +++++++++++++
 newlib/libc/stdbit/stdc_first_leading_zero.c  |  57 ++++++++
 newlib/libc/stdbit/stdc_first_trailing_one.3  | 110 ++++++++++++++++
 newlib/libc/stdbit/stdc_first_trailing_one.c  |  52 ++++++++
 newlib/libc/stdbit/stdc_first_trailing_zero.3 |  93 +++++++++++++
 newlib/libc/stdbit/stdc_first_trailing_zero.c |  53 ++++++++
 newlib/libc/stdbit/stdc_has_single_bit.3      |  98 ++++++++++++++
 newlib/libc/stdbit/stdc_has_single_bit.c      |  38 ++++++
 newlib/libc/stdbit/stdc_leading_ones.3        |  86 ++++++++++++
 newlib/libc/stdbit/stdc_leading_ones.c        |  60 +++++++++
 newlib/libc/stdbit/stdc_leading_zeros.3       |  86 ++++++++++++
 newlib/libc/stdbit/stdc_leading_zeros.c       |  60 +++++++++
 newlib/libc/stdbit/stdc_trailing_ones.3       |  86 ++++++++++++
 newlib/libc/stdbit/stdc_trailing_ones.c       |  56 ++++++++
 newlib/libc/stdbit/stdc_trailing_zeros.3      |  87 ++++++++++++
 newlib/libc/stdbit/stdc_trailing_zeros.c      |  56 ++++++++
 31 files changed, 2150 insertions(+)
 create mode 100644 newlib/libc/include/stdbit.h
 create mode 100644 newlib/libc/stdbit/Makefile.inc
 create mode 100644 newlib/libc/stdbit/stdc_bit_ceil.3
 create mode 100644 newlib/libc/stdbit/stdc_bit_ceil.c
 create mode 100644 newlib/libc/stdbit/stdc_bit_floor.3
 create mode 100644 newlib/libc/stdbit/stdc_bit_floor.c
 create mode 100644 newlib/libc/stdbit/stdc_bit_width.3
 create mode 100644 newlib/libc/stdbit/stdc_bit_width.c
 create mode 100644 newlib/libc/stdbit/stdc_count_ones.3
 create mode 100644 newlib/libc/stdbit/stdc_count_ones.c
 create mode 100644 newlib/libc/stdbit/stdc_count_zeros.3
 create mode 100644 newlib/libc/stdbit/stdc_count_zeros.c
 create mode 100644 newlib/libc/stdbit/stdc_first_leading_one.3
 create mode 100644 newlib/libc/stdbit/stdc_first_leading_one.c
 create mode 100644 newlib/libc/stdbit/stdc_first_leading_zero.3
 create mode 100644 newlib/libc/stdbit/stdc_first_leading_zero.c
 create mode 100644 newlib/libc/stdbit/stdc_first_trailing_one.3
 create mode 100644 newlib/libc/stdbit/stdc_first_trailing_one.c
 create mode 100644 newlib/libc/stdbit/stdc_first_trailing_zero.3
 create mode 100644 newlib/libc/stdbit/stdc_first_trailing_zero.c
 create mode 100644 newlib/libc/stdbit/stdc_has_single_bit.3
 create mode 100644 newlib/libc/stdbit/stdc_has_single_bit.c
 create mode 100644 newlib/libc/stdbit/stdc_leading_ones.3
 create mode 100644 newlib/libc/stdbit/stdc_leading_ones.c
 create mode 100644 newlib/libc/stdbit/stdc_leading_zeros.3
 create mode 100644 newlib/libc/stdbit/stdc_leading_zeros.c
 create mode 100644 newlib/libc/stdbit/stdc_trailing_ones.3
 create mode 100644 newlib/libc/stdbit/stdc_trailing_ones.c
 create mode 100644 newlib/libc/stdbit/stdc_trailing_zeros.3
 create mode 100644 newlib/libc/stdbit/stdc_trailing_zeros.c
  

On Fri, Mar 13, 2026 at 12:48 PM Howland, Craig D. - US <
craig.howland@caci.com> wrote:

>
> ------------------------------
> *From:* Joel Sherrill <joel@rtems.org>
> *Sent:* Friday, March 13, 2026 1:03 PM
> *To:* newlib@sourceware.org <newlib@sourceware.org>
> *Cc:* Joel Sherrill <joel@rtems.org>
> *Subject:* [PATCH v0 0/2] Add C23 stdbit.h functions
>
> >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
> <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.
> >
> >But the first problem is getting it to build at all.
> >
> >Help appreciated.
> >
> > Joel Sherrill (2):
> Joel:
> One question:  what about checks for the underlying __builtin* functions
> called?  I know (newer) GCC has them, but do all the supported compilers?
> (In the latter case, perhaps the to-be-added C23 check would implicitly
> handle that?)
>

Checking what I have installed, gcc 14 defaults to C17 and setting -std=c23
gives  __STDC_VERSION__  of 202000L. I think that means it will take GCC 15
or newer to get by the __STDC_VERSION__ check.

GCC 15 also does not provide stdckdint.h but gcc master does.

I haven't dived into support for new keywords but remember finding out
RTEMS had used one of the new keywords has a function name in a test. So
some of those are supported.

I **think** this means that GCC < 15 isn't going to build these.

I have not done an exhaustive pass on multilib variants for missing
__builtin* functions but I did a test build for -m68000 and it called
libgcc2 functions instead.

(Sorry, no ideas on the make problem.)
>

Me either. I thought that would be easier than it has turned out to be.

FWIW the patches are (1) import the o=unchanged source, (2) build changes.
The check for __STDC_VERSION__ needs to be added. I can add that to (2) or
add a (3) for that.

--joel


> Craig
>
> ------------------------------
>
> This electronic message contains information from CACI International Inc
> or subsidiary companies, which may be company sensitive, proprietary,
> privileged or otherwise protected from disclosure. The information is
> intended to be used solely by the recipient(s) named above. If you are not
> an intended recipient, be aware that any review, disclosure, copying,
> distribution or use of this transmission or its contents is prohibited. If
> you have received this transmission in error, please notify the sender
> immediately.
>
  

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.

- 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.

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.?


Thanks,
Corinna
  

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
>
  

On Mar 17 18:04, Joel Sherrill wrote:
> On Tue, Mar 17, 2026 at 12:35 PM Corinna Vinschen <corinna@vinschen.de>
> > 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.

Yes, please.

> 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

I think that's a bug in automake 1.16.5.  Doesn't occur with 1.15.1.

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

Btw., you should probbaly make sure these functions are only built
in ELIX_LEVEL > 3, see libc/search/Makefile.inc line 28ff.


Corinna
  

On Mar 18 12:27, Corinna Vinschen wrote:
> On Mar 17 18:04, Joel Sherrill wrote:
> > On Tue, Mar 17, 2026 at 12:35 PM Corinna Vinschen <corinna@vinschen.de>
> > > 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.
> 
> Yes, please.
> 
> > 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
> 
> I think that's a bug in automake 1.16.5.  Doesn't occur with 1.15.1.
> 
> > Sorry to be a problem. I just do not seem to be able to regenerate a
> > working Makefile.in
> > 
> > Help appreciated.
> 
> Btw., you should probbaly make sure these functions are only built
> in ELIX_LEVEL > 3, see libc/search/Makefile.inc line 28ff.

Oh, and make sure to update to latest origin/main.  I pushed changes
to the configury yesterday.


Corinna
  

Thanks. I finally aligned all the autotools versions with your changes.

It all built for me to target sparc-rtems7.

You mentioned a problem compiling these earlier. What target was that? I
think all the
XXX_WIDTH constants used are in limits.h.

And is there any organization behind ELIX and ELIX_LEVEL anymore? Is 3
everything or some restricted subset. We would like them on RTEMS and I
assume we would be a more restricted profile since we are single process.

Thanks.

--joel

On Wed, Mar 18, 2026 at 6:31 AM Corinna Vinschen <corinna@vinschen.de>
wrote:

> On Mar 18 12:27, Corinna Vinschen wrote:
> > On Mar 17 18:04, Joel Sherrill wrote:
> > > On Tue, Mar 17, 2026 at 12:35 PM Corinna Vinschen <corinna@vinschen.de
> >
> > > > 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.
> >
> > Yes, please.
> >
> > > 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
> >
> > I think that's a bug in automake 1.16.5.  Doesn't occur with 1.15.1.
> >
> > > Sorry to be a problem. I just do not seem to be able to regenerate a
> > > working Makefile.in
> > >
> > > Help appreciated.
> >
> > Btw., you should probbaly make sure these functions are only built
> > in ELIX_LEVEL > 3, see libc/search/Makefile.inc line 28ff.
>
> Oh, and make sure to update to latest origin/main.  I pushed changes
> to the configury yesterday.
>
>
> Corinna
>
  

Hi Joel,

On Mar 21 18:52, Joel Sherrill wrote:
> Thanks. I finally aligned all the autotools versions with your changes.
> 
> It all built for me to target sparc-rtems7.
> 
> You mentioned a problem compiling these earlier. What target was that? I
> think all the
> XXX_WIDTH constants used are in limits.h.

No, they are not.  Target was Cygwin with its own limits.h, but even in
newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
they are not defined anywhere in the newlib-cygwin repo.  If this works
for you, you're probably overloading the newlib headers with rtems
headers.

> And is there any organization behind ELIX and ELIX_LEVEL anymore? Is 3
> everything or some restricted subset. We would like them on RTEMS and I
> assume we would be a more restricted profile since we are single process.

Actually, I don't know.  I thought we're supposed to maintain this
stuff.

Jeff?

If this isn't important anymore, fine with me, it just complicates
the configury anyway ;)


Thanks,
Corinna
  

Regarding ELIX, ELIX 1 is the smallest subset of the library and ELIX 4, or
not specifying ELIX, is everything.  In general, adding new
shared functions should go in ELIX 4 as the original ELIX documentation
wouldn't have categorized the new functions.

I don't know if anyone is currently using the ELIX settings.

-- Jeff J.

On Mon, Mar 23, 2026 at 4:59 AM Corinna Vinschen <corinna@vinschen.de>
wrote:

> Hi Joel,
>
> On Mar 21 18:52, Joel Sherrill wrote:
> > Thanks. I finally aligned all the autotools versions with your changes.
> >
> > It all built for me to target sparc-rtems7.
> >
> > You mentioned a problem compiling these earlier. What target was that? I
> > think all the
> > XXX_WIDTH constants used are in limits.h.
>
> No, they are not.  Target was Cygwin with its own limits.h, but even in
> newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
> they are not defined anywhere in the newlib-cygwin repo.  If this works
> for you, you're probably overloading the newlib headers with rtems
> headers.
>
> > And is there any organization behind ELIX and ELIX_LEVEL anymore? Is 3
> > everything or some restricted subset. We would like them on RTEMS and I
> > assume we would be a more restricted profile since we are single process.
>
> Actually, I don't know.  I thought we're supposed to maintain this
> stuff.
>
> Jeff?
>
> If this isn't important anymore, fine with me, it just complicates
> the configury anyway ;)
>
>
> Thanks,
> Corinna
>
>
  

Sorry for the delay. I got back to Corrina's comment:

> No, they are not.  Target was Cygwin with its own limits.h, but even in
> newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
> they are not defined anywhere in the newlib-cygwin repo.  If this works
> for you, you're probably overloading the newlib headers with rtems
> headers.

RTEMS does indeed have its own limits.h. And it must be aligned with  C23.

And Cygwin has its own limits.h which has not been updated to have any of
the new C23 constants. Four show up in compiler error messages building
the stdbit code.

https://en.cppreference.com/w/c/header/limits.html

The stdbit.h addition needs a limits.h with the C23 constants.

Can those be added to the Cygwin limits.h? Then we can proceed with
the stdbit.h addition.

Thanks.

--joel



On Mon, Mar 23, 2026 at 3:55 PM Jeff Johnston <jjohnstn@redhat.com> wrote:

> Regarding ELIX, ELIX 1 is the smallest subset of the library and ELIX 4,
> or not specifying ELIX, is everything.  In general, adding new
> shared functions should go in ELIX 4 as the original ELIX documentation
> wouldn't have categorized the new functions.
>
> I don't know if anyone is currently using the ELIX settings.
>
> -- Jeff J.
>
> On Mon, Mar 23, 2026 at 4:59 AM Corinna Vinschen <corinna@vinschen.de>
> wrote:
>
>> Hi Joel,
>>
>> On Mar 21 18:52, Joel Sherrill wrote:
>> > Thanks. I finally aligned all the autotools versions with your changes.
>> >
>> > It all built for me to target sparc-rtems7.
>> >
>> > You mentioned a problem compiling these earlier. What target was that? I
>> > think all the
>> > XXX_WIDTH constants used are in limits.h.
>>
>> No, they are not.  Target was Cygwin with its own limits.h, but even in
>> newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
>> they are not defined anywhere in the newlib-cygwin repo.  If this works
>> for you, you're probably overloading the newlib headers with rtems
>> headers.
>>
>> > And is there any organization behind ELIX and ELIX_LEVEL anymore? Is 3
>> > everything or some restricted subset. We would like them on RTEMS and I
>> > assume we would be a more restricted profile since we are single
>> process.
>>
>> Actually, I don't know.  I thought we're supposed to maintain this
>> stuff.
>>
>> Jeff?
>>
>> If this isn't important anymore, fine with me, it just complicates
>> the configury anyway ;)
>>
>>
>> Thanks,
>> Corinna
>>
>>
  

On 2026-04-03 11:14, Joel Sherrill wrote:
> Sorry for the delay. I got back to Corrina's comment:
> 
>  > No, they are not.  Target was Cygwin with its own limits.h, but even in
>  > newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
>  > they are not defined anywhere in the newlib-cygwin repo.  If this works
>  > for you, you're probably overloading the newlib headers with rtems
>  > headers.
> 
> RTEMS does indeed have its own limits.h. And it must be aligned with  C23.
> 
> And Cygwin has its own limits.h which has not been updated to have any of
> the new C23 constants. Four show up in compiler error messages building
> the stdbit code.
> 
> https://en.cppreference.com/w/c/header/limits.html
> <https://en.cppreference.com/w/c/header/limits.html>
> 
> The stdbit.h addition needs a limits.h with the C23 constants.
> 
> Can those be added to the Cygwin limits.h? Then we can proceed with
> the stdbit.h addition.

For fastest response, please submit a patch with subject like:

[PATCH] Cygwin: winsup/cygwin/include/limits.h: Add C23 ..._WIDTH definitions

similar to your RTEMS changes, using normal feature test macros as appropriate, 
with git format-patch & git send-email to:

Cygwin core component patch submission and discussion
						<cygwin-patches@cygwin.com>

> On Mon, Mar 23, 2026 at 3:55 PM Jeff Johnston <jjohnstn@redhat.com 
> <mailto:jjohnstn@redhat.com>> wrote:
> 
>     Regarding ELIX, ELIX 1 is the smallest subset of the library and ELIX 4, or
>     not specifying ELIX, is everything.  In general, adding new
>     shared functions should go in ELIX 4 as the original ELIX documentation
>     wouldn't have categorized the new functions.
> 
>     I don't know if anyone is currently using the ELIX settings.
> 
>     -- Jeff J.
> 
>     On Mon, Mar 23, 2026 at 4:59 AM Corinna Vinschen <corinna@vinschen.de
>     <mailto:corinna@vinschen.de>> wrote:
> 
>         Hi Joel,
> 
>         On Mar 21 18:52, Joel Sherrill wrote:
>          > Thanks. I finally aligned all the autotools versions with your changes.
>          >
>          > It all built for me to target sparc-rtems7.
>          >
>          > You mentioned a problem compiling these earlier. What target was that? I
>          > think all the
>          > XXX_WIDTH constants used are in limits.h.
> 
>         No, they are not.  Target was Cygwin with its own limits.h, but even in
>         newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
>         they are not defined anywhere in the newlib-cygwin repo.  If this works
>         for you, you're probably overloading the newlib headers with rtems
>         headers.
> 
>          > And is there any organization behind ELIX and ELIX_LEVEL anymore? Is 3
>          > everything or some restricted subset. We would like them on RTEMS and I
>          > assume we would be a more restricted profile since we are single process.
> 
>         Actually, I don't know.  I thought we're supposed to maintain this
>         stuff.
> 
>         Jeff?
> 
>         If this isn't important anymore, fine with me, it just complicates
>         the configury anyway ;)
> 
> 
>         Thanks,
>         Corinna
>
  

On Apr  3 17:08, Brian Inglis wrote:
> On 2026-04-03 11:14, Joel Sherrill wrote:
> > Sorry for the delay. I got back to Corrina's comment:
> > 
> >  > No, they are not.  Target was Cygwin with its own limits.h, but even in
> >  > newlib's limits.h, these WIDTH macros are not defined.  Incidentally,
> >  > they are not defined anywhere in the newlib-cygwin repo.  If this works
> >  > for you, you're probably overloading the newlib headers with rtems
> >  > headers.
> > 
> > RTEMS does indeed have its own limits.h. And it must be aligned with  C23.
> > 
> > And Cygwin has its own limits.h which has not been updated to have any of
> > the new C23 constants. Four show up in compiler error messages building
> > the stdbit code.
> > 
> > https://en.cppreference.com/w/c/header/limits.html
> > <https://en.cppreference.com/w/c/header/limits.html>
> > 
> > The stdbit.h addition needs a limits.h with the C23 constants.
> > 
> > Can those be added to the Cygwin limits.h? Then we can proceed with
> > the stdbit.h addition.
> 
> For fastest response, please submit a patch with subject like:
> 
> [PATCH] Cygwin: winsup/cygwin/include/limits.h: Add C23 ..._WIDTH definitions
> 
> similar to your RTEMS changes, using normal feature test macros as
> appropriate, with git format-patch & git send-email to:
> 
> Cygwin core component patch submission and discussion
> 						<cygwin-patches@cygwin.com>

Either that (patches are always welcome), or just use the
compiler-provided constants.


Thanks,
Corinna
  

Looking closer, these are not coming from the "OS's" limits.h.
They are defined by GCC's limits.h. I checked an older RTEMS
toolchain to see how far back these were present. These are
not a recent addition.

lib/gcc/sparc-rtems6/13.3.0/include/limits.h
lib/gcc/microblaze-rtems6/12.4.1/include-fixed/limits.h

On my freshly updated Cygwin, I found that the gcc install included
a similar limits.h with ULLONG_WIDTH defined. So it is there but
not via the Cygwin limits.h.

lib/gcc/x86_64-pc-cygwin/13/include/limits.h:# define ULLONG_WIDTH
__LONG_LONG_WIDTH__

The problem appears to be that the Cygwin specific limits.h is
missing this code fragment that the RTEMS limits.h has.

#ifndef _GCC_LIMITS_H_  /* if we have not seen gcc's limits.h yet */
#include_next <limits.h>
#endif

But Cygwin's limits.h has its own defines for constants GCC's limits.h
provides which leads me to believe that Cygwin wants its limits.h to
be self-contained and not rely on GCC's. GCC's limits.h has a block
which defines all the _WIDTH constants like this:

#if (defined __STDC_WANT_IEC_60559_BFP_EXT__ \
     || (defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L))
/* TS 18661-1 / C2X widths of integer types.  */
# undef CHAR_WIDTH
# define CHAR_WIDTH __SCHAR_WIDTH__
.... redacted
# undef ULLONG_WIDTH
# define ULLONG_WIDTH __LONG_LONG_WIDTH__
#endif

I can add all of that to the Cygwin limits.h as a single block and
submit a patch. Is that an acceptable solution?

Also I have no way of testing this. I can submit an untested patch.
Is that really OK?

I don't mind doing this. But submitting untested patches
makes me uncomfortable. Is someone willing to test this?

--joel

On Tue, Apr 7, 2026 at 10:57 AM Corinna Vinschen <corinna@vinschen.de>
wrote:

> On Apr  3 17:08, Brian Inglis wrote:
> > On 2026-04-03 11:14, Joel Sherrill wrote:
> > > Sorry for the delay. I got back to Corrina's comment:
> > >
> > >  > No, they are not.  Target was Cygwin with its own limits.h, but
> even in
> > >  > newlib's limits.h, these WIDTH macros are not defined.
> Incidentally,
> > >  > they are not defined anywhere in the newlib-cygwin repo.  If this
> works
> > >  > for you, you're probably overloading the newlib headers with rtems
> > >  > headers.
> > >
> > > RTEMS does indeed have its own limits.h. And it must be aligned with
> C23.
> > >
> > > And Cygwin has its own limits.h which has not been updated to have any
> of
> > > the new C23 constants. Four show up in compiler error messages building
> > > the stdbit code.
> > >
> > > https://en.cppreference.com/w/c/header/limits.html
> > > <https://en.cppreference.com/w/c/header/limits.html>
> > >
> > > The stdbit.h addition needs a limits.h with the C23 constants.
> > >
> > > Can those be added to the Cygwin limits.h? Then we can proceed with
> > > the stdbit.h addition.
> >
> > For fastest response, please submit a patch with subject like:
> >
> > [PATCH] Cygwin: winsup/cygwin/include/limits.h: Add C23 ..._WIDTH
> definitions
> >
> > similar to your RTEMS changes, using normal feature test macros as
> > appropriate, with git format-patch & git send-email to:
> >
> > Cygwin core component patch submission and discussion
> >                                               <cygwin-patches@cygwin.com
> >
>
> Either that (patches are always welcome), or just use the
> compiler-provided constants.
>
>
> Thanks,
> Corinna
>
  

I submitted a patch to cygwin-patches. I do not see it in the archives
at https://cygwin.com/pipermail/cygwin-patches/2026q2/date.html.
If it is caught at the moderator, please let it go through.

Thanks.

--joel

On Tue, Apr 7, 2026 at 5:22 PM Joel Sherrill <joel.sherrill@gmail.com>
wrote:

> Looking closer, these are not coming from the "OS's" limits.h.
> They are defined by GCC's limits.h. I checked an older RTEMS
> toolchain to see how far back these were present. These are
> not a recent addition.
>
> lib/gcc/sparc-rtems6/13.3.0/include/limits.h
> lib/gcc/microblaze-rtems6/12.4.1/include-fixed/limits.h
>
> On my freshly updated Cygwin, I found that the gcc install included
> a similar limits.h with ULLONG_WIDTH defined. So it is there but
> not via the Cygwin limits.h.
>
> lib/gcc/x86_64-pc-cygwin/13/include/limits.h:# define ULLONG_WIDTH
> __LONG_LONG_WIDTH__
>
> The problem appears to be that the Cygwin specific limits.h is
> missing this code fragment that the RTEMS limits.h has.
>
> #ifndef _GCC_LIMITS_H_  /* if we have not seen gcc's limits.h yet */
> #include_next <limits.h>
> #endif
>
> But Cygwin's limits.h has its own defines for constants GCC's limits.h
> provides which leads me to believe that Cygwin wants its limits.h to
> be self-contained and not rely on GCC's. GCC's limits.h has a block
> which defines all the _WIDTH constants like this:
>
> #if (defined __STDC_WANT_IEC_60559_BFP_EXT__ \
>      || (defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L))
> /* TS 18661-1 / C2X widths of integer types.  */
> # undef CHAR_WIDTH
> # define CHAR_WIDTH __SCHAR_WIDTH__
> .... redacted
> # undef ULLONG_WIDTH
> # define ULLONG_WIDTH __LONG_LONG_WIDTH__
> #endif
>
> I can add all of that to the Cygwin limits.h as a single block and
> submit a patch. Is that an acceptable solution?
>
> Also I have no way of testing this. I can submit an untested patch.
> Is that really OK?
>
> I don't mind doing this. But submitting untested patches
> makes me uncomfortable. Is someone willing to test this?
>
> --joel
>
> On Tue, Apr 7, 2026 at 10:57 AM Corinna Vinschen <corinna@vinschen.de>
> wrote:
>
>> On Apr  3 17:08, Brian Inglis wrote:
>> > On 2026-04-03 11:14, Joel Sherrill wrote:
>> > > Sorry for the delay. I got back to Corrina's comment:
>> > >
>> > >  > No, they are not.  Target was Cygwin with its own limits.h, but
>> even in
>> > >  > newlib's limits.h, these WIDTH macros are not defined.
>> Incidentally,
>> > >  > they are not defined anywhere in the newlib-cygwin repo.  If this
>> works
>> > >  > for you, you're probably overloading the newlib headers with rtems
>> > >  > headers.
>> > >
>> > > RTEMS does indeed have its own limits.h. And it must be aligned with
>> C23.
>> > >
>> > > And Cygwin has its own limits.h which has not been updated to have
>> any of
>> > > the new C23 constants. Four show up in compiler error messages
>> building
>> > > the stdbit code.
>> > >
>> > > https://en.cppreference.com/w/c/header/limits.html
>> > > <https://en.cppreference.com/w/c/header/limits.html>
>> > >
>> > > The stdbit.h addition needs a limits.h with the C23 constants.
>> > >
>> > > Can those be added to the Cygwin limits.h? Then we can proceed with
>> > > the stdbit.h addition.
>> >
>> > For fastest response, please submit a patch with subject like:
>> >
>> > [PATCH] Cygwin: winsup/cygwin/include/limits.h: Add C23 ..._WIDTH
>> definitions
>> >
>> > similar to your RTEMS changes, using normal feature test macros as
>> > appropriate, with git format-patch & git send-email to:
>> >
>> > Cygwin core component patch submission and discussion
>> >                                               <
>> cygwin-patches@cygwin.com>
>>
>> Either that (patches are always welcome), or just use the
>> compiler-provided constants.
>>
>>
>> Thanks,
>> Corinna
>>
>
  

OK. It was rejected as I wasn't subscribed. Resent after subscribing
and they now are in the cygwin-patches archive.

Thanks.

--joel

On Wed, Apr 8, 2026 at 10:16 AM Joel Sherrill <joel.sherrill@gmail.com>
wrote:

> I submitted a patch to cygwin-patches. I do not see it in the archives
> at https://cygwin.com/pipermail/cygwin-patches/2026q2/date.html.
> If it is caught at the moderator, please let it go through.
>
> Thanks.
>
> --joel
>
> On Tue, Apr 7, 2026 at 5:22 PM Joel Sherrill <joel.sherrill@gmail.com>
> wrote:
>
>> Looking closer, these are not coming from the "OS's" limits.h.
>> They are defined by GCC's limits.h. I checked an older RTEMS
>> toolchain to see how far back these were present. These are
>> not a recent addition.
>>
>> lib/gcc/sparc-rtems6/13.3.0/include/limits.h
>> lib/gcc/microblaze-rtems6/12.4.1/include-fixed/limits.h
>>
>> On my freshly updated Cygwin, I found that the gcc install included
>> a similar limits.h with ULLONG_WIDTH defined. So it is there but
>> not via the Cygwin limits.h.
>>
>> lib/gcc/x86_64-pc-cygwin/13/include/limits.h:# define ULLONG_WIDTH
>> __LONG_LONG_WIDTH__
>>
>> The problem appears to be that the Cygwin specific limits.h is
>> missing this code fragment that the RTEMS limits.h has.
>>
>> #ifndef _GCC_LIMITS_H_  /* if we have not seen gcc's limits.h yet */
>> #include_next <limits.h>
>> #endif
>>
>> But Cygwin's limits.h has its own defines for constants GCC's limits.h
>> provides which leads me to believe that Cygwin wants its limits.h to
>> be self-contained and not rely on GCC's. GCC's limits.h has a block
>> which defines all the _WIDTH constants like this:
>>
>> #if (defined __STDC_WANT_IEC_60559_BFP_EXT__ \
>>      || (defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L))
>> /* TS 18661-1 / C2X widths of integer types.  */
>> # undef CHAR_WIDTH
>> # define CHAR_WIDTH __SCHAR_WIDTH__
>> .... redacted
>> # undef ULLONG_WIDTH
>> # define ULLONG_WIDTH __LONG_LONG_WIDTH__
>> #endif
>>
>> I can add all of that to the Cygwin limits.h as a single block and
>> submit a patch. Is that an acceptable solution?
>>
>> Also I have no way of testing this. I can submit an untested patch.
>> Is that really OK?
>>
>> I don't mind doing this. But submitting untested patches
>> makes me uncomfortable. Is someone willing to test this?
>>
>> --joel
>>
>> On Tue, Apr 7, 2026 at 10:57 AM Corinna Vinschen <corinna@vinschen.de>
>> wrote:
>>
>>> On Apr  3 17:08, Brian Inglis wrote:
>>> > On 2026-04-03 11:14, Joel Sherrill wrote:
>>> > > Sorry for the delay. I got back to Corrina's comment:
>>> > >
>>> > >  > No, they are not.  Target was Cygwin with its own limits.h, but
>>> even in
>>> > >  > newlib's limits.h, these WIDTH macros are not defined.
>>> Incidentally,
>>> > >  > they are not defined anywhere in the newlib-cygwin repo.  If this
>>> works
>>> > >  > for you, you're probably overloading the newlib headers with rtems
>>> > >  > headers.
>>> > >
>>> > > RTEMS does indeed have its own limits.h. And it must be aligned
>>> with  C23.
>>> > >
>>> > > And Cygwin has its own limits.h which has not been updated to have
>>> any of
>>> > > the new C23 constants. Four show up in compiler error messages
>>> building
>>> > > the stdbit code.
>>> > >
>>> > > https://en.cppreference.com/w/c/header/limits.html
>>> > > <https://en.cppreference.com/w/c/header/limits.html>
>>> > >
>>> > > The stdbit.h addition needs a limits.h with the C23 constants.
>>> > >
>>> > > Can those be added to the Cygwin limits.h? Then we can proceed with
>>> > > the stdbit.h addition.
>>> >
>>> > For fastest response, please submit a patch with subject like:
>>> >
>>> > [PATCH] Cygwin: winsup/cygwin/include/limits.h: Add C23 ..._WIDTH
>>> definitions
>>> >
>>> > similar to your RTEMS changes, using normal feature test macros as
>>> > appropriate, with git format-patch & git send-email to:
>>> >
>>> > Cygwin core component patch submission and discussion
>>> >                                               <
>>> cygwin-patches@cygwin.com>
>>>
>>> Either that (patches are always welcome), or just use the
>>> compiler-provided constants.
>>>
>>>
>>> Thanks,
>>> Corinna
>>>
>>
  

On Apr  8 10:34, Joel Sherrill wrote:
> OK. It was rejected as I wasn't subscribed. Resent after subscribing
> and they now are in the cygwin-patches archive.

I pushed it yesterday, thank you.

Feel free to send V2 of your stdbit patch series.


Thanks,
Corinna