Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something?

On May 31, 2023, at 11:11, Mark Millard <marklmi@yahoo.com> wrote:

> On May 31, 2023, at 06:11, José Pérez <fbl@aoek.com> wrote:
> 
>> Hi,
> 
> Hello.
> 
>> El 2023-05-27 15:21, Mark Millard escribió:
>>> On May 27, 2023, at 05:27, Mark Millard <marklmi@yahoo.com> wrote:
>>> It is unclear what you are doing for linking.
>> 
>> Linking is another chapter that will be written after we can obtain objects.
>> 
>> For the time being I am buinding a number of tests to see if the headers are functional or not, following your suggestion to add newlib ports header path first, and then arm-noabi-gcc header paths. I.e.
>> #include <...> search starts here:
>> /usr/local/arm-none-eabi/include
>> /usr/local/lib/gcc/arm-none-eabi/11.3.0/include
>> /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed
>> End of search list.
>> 
>> In this scenario the next problem I am hitting is this one:
>> % arm-none-eabi-gcc test_stdatomic.c -c -g -DDEBUG -pipe -nostdinc -isystem /usr/local/arm-none-eabi/include -isystem /usr/local/lib/gcc/arm-none-eabi/11.3.0/include -isystem /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed -o test_stdatomic.o
>> In file included from test_stdatomic.c:2:
>> /usr/local/arm-none-eabi/include/stdatomic.h: In function 'atomic_flag_test_and_set_explicit':
>> /usr/local/arm-none-eabi/include/stdatomic.h:386:17: error: request for member '__val' in something not a structure or union
>> 386 |         return (atomic_exchange_explicit(&__object->__flag, 1, __order));
>>     |                 ^~~~~~~~~~~~~~~~~~~~~~~~
>> /usr/local/arm-none-eabi/include/stdatomic.h: In function 'atomic_flag_clear_explicit':
>> /usr/local/arm-none-eabi/include/stdatomic.h:393:9: error: request for member '__val' in something not a structure or union
>> 393 |         atomic_store_explicit(&__object->__flag, 0, __order);
>>     |         ^~~~~~~~~~~~~~~~~~~~~
>> 
>> % cat test_stdatomic.c
>> #include <stdint.h>
>> #include <stdatomic.h>
>> 
>> int main(int argc, char *argv[]) {
>> return 0;
>> }
>> 
>> Any suggestion before I patch /usr/local/arm-none-eabi/include/stdatomic.h to make it work?
>> 
> 
> # arm-none-eabi-gcc -std=c99 test_stdatomic.c -c -g -DDEBUG -pipe -nostdinc -isystem /usr/local/arm-none-eabi/include -isystem /usr/local/lib/gcc/arm-none-eabi/11.3.0/include -isystem /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed -o test_stdatomic.o
> #
> 
> So: with -std=c99 added your command works fine. But using -std=c11 (even implicitly)
> does not:
> 
> # arm-none-eabi-gcc -std=c11 test_stdatomic.c -c -g -DDEBUG -pipe -nostdinc -isystem /usr/local/arm-none-eabi/include -isystem /usr/local/lib/gcc/arm-none-eabi/11.3.0/include -isystem /usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed -o test_stdatomic.o
> In file included from test_stdatomic.c:2:
> /usr/local/arm-none-eabi/include/stdatomic.h: In function 'atomic_flag_test_and_set_explicit':
> /usr/local/arm-none-eabi/include/stdatomic.h:386:17: error: request for member '__val' in something not a structure or union
>  386 |         return (atomic_exchange_explicit(&__object->__flag, 1, __order));
>      |                 ^~~~~~~~~~~~~~~~~~~~~~~~
> /usr/local/arm-none-eabi/include/stdatomic.h: In function 'atomic_flag_clear_explicit':
> /usr/local/arm-none-eabi/include/stdatomic.h:393:9: error: request for member '__val' in something not a structure or union
>  393 |         atomic_store_explicit(&__object->__flag, 0, __order);
>      |         ^~~~~~~~~~~~~~~~~~~~~
> 
> Note that c11 added builtin atomics. It appears that
> devel/arm-none-eabi-newlib does not yet correctly
> handle such contexts, at least for what arm-none-eabi-gcc
> provides relative to c11.
> 
> Is use of -std=c99 inappropriate to your purpose? Do
> you need to use c11 (or later)?
> 

I will note that newlib's NEWS file:

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/NEWS;h=ee456f9b8a25ea96d31013383b1ad56eed6afa03;hb=HEAD

mentions C99 various times over the years, but never
mentions any of C11, C17, or C23.

Looking at the materials, they appear to be incoherent
for things added/changed by C11 and later.

Overall: it looks like C11 and later are just not supported
upstream.

===
Mark Millard
marklmi at yahoo.com