Re: C99 support in Newlib

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

On 1/14/2016 10:42 AM, Andre Vieira (lists) wrote:
> On 14/01/16 15:27, Joel Sherrill wrote:
> > On 1/14/2016 8:04 AM, Andre Vieira (lists) wrote:
> > > On 11/01/16 14:27, Andre Vieira (lists) wrote:
> > > > On 20/01/15 11:49, Freddie Chopin wrote:
> > > > > On 01/20/2015 12:46 PM, Corinna Vinschen wrote:
> > > > > > On Jan 20 12:21, Freddie Chopin wrote:
> > > > > > > On 01/20/2015 11:06 AM, Corinna Vinschen wrote:
> > > > > > > > On Jan 20 17:19, Joey Ye wrote:
> > > > > > > > > Corinna, May I know which features are missing please?
> > > > > > > > As far as I can tell, mainly the long double functions for targets
> > > > > > > > with sizeof(double) != sizeof(long double).
> > > > > > > I have one more - from my recent browsing of scanf() code, I assume
> > > > > > > that
> > > > > > > "%[...]" is supported, but "%[^...]" is not.
> > > > > > No, it is.  See libc/stdio/sccl.c.
> > > > >
> > > > > Right, my mistake (; Sorry for the noise then (;
> > > > >
> > > > > Regards,
> > > > > FCh
> > > >
> > > > Hi there,
> > > >
> > > > I thought I'd reply to this thread as it is very much related to my
> > > > issue.
> > > >
> > > > In a recent GCC patch a change to an optimization, which now checks for
> > > > the existence of libc support for C99 functions, lead to a regression
> > > > for arm-none-eabi. This is because currently GCC is set up to assume no
> > > > C99 support is available for arm-none-eabi. As far as I know this is
> > > > because it comes with newlib and as this thread points out it does not
> > > > claim to fully support C99. See
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69227
> > > >
> > > > Hopefully with some help I can figure out what GCC 'function classes'
> > > > can be seen as supported by newlib for arm-none-eabi. These function
> > > > classes are:
> > > >
> > > > function_c94:
> > > >       functions only part of the standard in C94 or above.
> > > > function_c99_misc:
> > > >       functions only part of the standard in C99 or above.
> > > > function_c99_math_complex:
> > > >       math complex functions only part of the standard in C99 or above.
> > > > function_c11_misc:
> > > >       functions only part of the standard in C11 or above
> > > >
> > > > And there is also 'function_sincos' for which I couldn't find a
> > > > definition though I assume its for the GNU extension 'sincos'.
> > > >
> > > > $arm-none-eabi-nm libm.a | grep sincos
> > > > lib_a-w_sincos.o:
> > > > 00000000 T sincos
> > > > lib_a-wf_sincos.o:
> > > > 00000000 T sincosf
> > > >
> > > >
> > > > Can someone confirm the support or lack thereof for these classes in
> > > > newlib for 'arm-none-eabi'.
> > > >
> > > > Thanks!
> > > >
> > > > BR,
> > > > Andre
> > >
> > > As an investigation exercise I constructed a list of all functions in
> > > the C99 standard and I checked whether the newlib version we build for
> > > arm-none-eabi defined these and I found that it was missing quite a lot
> > > of them! See attached file.
> > >
> > > That answers my question for the bugzilla ticket. We can not enable
> > > function_c99_* function class support for arm-none-eabi.
> >
> > I think you checked it against C11. I spotted thrd_create on the list
> > and don't think that is C99.
> >
> > My quick impression is:
> >
> > +  to agree that the math methods are C99 and missing.
> > + thread, mutex and other concurrency objects are C11
> > + *_s is C11
> > + timespec_get is C11
> >
> > At least that's based on cppreference.com. Did I miss something?
> >
> > I agree a complete set of C99 methods is important.
> >
> > C11 adds some things which newlib should support and others which
> > are the domain of the hosting environment. Newlib doesn't support
> > pthreads for example (but has pthread.h) so C11 threads should
> > follow the same pattern.
> >
> > > Cheers,
> > > Andre
> Yes I did, sorry for the noise. I am also chasing this up on gcc-patches
> ml as its related to an open issue:
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00925.html
>
>
> I had categorized the missing functions into:
> - Complex Arithmetic (which fall under the function_c99_math_complex class)
> - floating-point environment
> - Functions for greatest-width integer types

More below but these all have c99 issues and are target independent.

> - atomics (missing atomic_is_lock_free and atomic_fetch_key)
> - Bounds-checking interfaces
>
> The last two are C11, as Szabolcs also pointed out in his reply:
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00934.html

Are you just looking at the Linux configuration of newlib for this?
I don't see atomic.h anywhere else.

RTEMS has its own atomic support.

Will the bounds checking interfaces be target independent?

> So the missing C99 functions are the:
> - Complex Arithmetic (all long double versions)

Yep. ~24 methods if I am counting right.

> - Floating-point environment

Basically fenv.h. 12-14 methods I think

> - Functions for greatest-width integer types.

Agreed. I think four methods are missing from inttypes.h

Are you planning on working on these? I ask because I was doing
a similar analysis for newlib's use with RTEMS. I was planning
on putting it up as a potential Google Summer of Code project
but it was going to be target independent newlib c99 deficiencies
plus a few odds and ends for RTEMS. My intention was to file
RTEMS tickets to track these and use those to compose the GSoC
project.

It would be good to coordinate and, if a student shows up,
leverage them.

> Cheers,
> Andre

--joel
RTEMS