Re: Source file structure for fenv.h support

[Joel Sherrill <joel at rtems dot org>]

On Tue, Jul 30, 2019 at 9:34 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

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

+1

>
> > Also newlib has fenv.cc although it looks like pure C at first glance.
>
> Do you mean Cygwin?  Newlib has no fenv.c{c}.
>

Yes. Sorry.  These files:

winsup/cygwin/include/fenv.h
winsup/cygwin/fenv.cc


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

I was considering just moving winsup/cygwin/fenv.cc to newlib as
a C file and fixing what was C++ specific.  But looking at what FreeBSD
has, it distinguishes i386 and amd64. Perhaps that is the best to use
in newlib. What do you think?

In general, it looks like x86 fenv implementations support both
x86 and x86_64. How to make a file shared across two architectures
in the newlib source? The include directory trick would imply there
needs to be a copy.


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

I think that is possible and easy although it will take a Cygwin developer
to test the split.

Thanks.

--joel



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