Re: Source file structure for fenv.h support

On Tue, Jul 30, 2019 at 2:37 AM Corinna Vinschen <[email protected]>
wrote:

> On Jul 29 13:48, Joel Sherrill wrote:
> > Hi
> >
> > Vaibhav is looking at porting *BSD fenv support for a few more
> > architectures. Right now, it looks like there is only SPU and RISC-V
> > support with this structure:
> >
> > - libc/machine/ARCH/include/fenv.h - portable POSIX interface, includes
> > sys/fenv.h
> > - libc/machine/ARCH/include/sys/fenv.h - architecture specific details.
> >
> > I think (but have not confirmed) that the RISC-V version is correct per
> > POSIX. The SPU version clearly is not as it does not have the right
> > signature for most of the methods as they all are supposed to return int
> > and not void.
> >
> > My proposal is to verify the RISC-V include/fenv.h is POSIX correct and
> > then move it to libc/include/fenv.h.For completeness, we may need a
> > minimal, non-functional sys/fenv.h which defines dummy fexcept_t and
> fenv_t
> > structures.  But it becomes the responsibility of a port to provide
> > <sys/fenv.h> and implementations.
> >
> > In the event a port provides the entire implementation as inlines, it can
> > override fenv.h.
> >
> > Does this make sense? Is it a good approach? I want to avoid duplicating
> a
> > pure POSIX version of fenv.h like RISC-V has.
>
> Sounds good to me, but please don't forget the Cygwin version of fenv.h.
> It's sys parts are basically the x86/x86_64 variation of the same, and
> it's pretty complete, including glibc-only and BSD-only functions.
>

I don't mind us splitting it but....

The Cygwin code is under the CYGWIN_LICENSE which is GPLv3+. I was
hoping it could be leveraged for x86 and x86_64 newlib libm support but the
license prevents that. Either that has to be relicensed or we just use *BSD
implementations in newilb/libm.

Also newlib has fenv.cc although it looks like pure C at first glance.

How best to procedure for x86* support?


>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
>