Re: Source file structure for fenv.h support

[Corinna Vinschen <vinschen at redhat dot com>]

On Jul 30 08:59, Joel Sherrill wrote:
> On Tue, Jul 30, 2019 at 2:37 AM Corinna Vinschen <vinschen@redhat.com>
> 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.

It can be relicensed to 2-clause BSD on demand when moving to newlib.

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

Do you mean Cygwin?  Newlib has no fenv.c{c}.

I thought you only move and fix up fenv.h.  That shouldn't affect
Cygwin's fenv.cc.

> How best to procedure for x86* support?

By just moving the x86-specific definitions to the not yet existing
libc/machine/{i386,x86_64}/sys/fenv.h, I thought.  Not feasible?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature