Re: Source file structure for fenv.h support

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On Jul 30 08:59, Joel Sherrill wrote:
> 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.

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
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1AVV8ACgkQ9TYGna5E
T6AEMQ//QRVQWNja/zCZHrptQgnZdS7o98F90NVavBOSv3HR5Apj6s25qAWSzAKI
vnecPhdNQHK1DV4BLECP9dpmw/AWovYzo1w+MDz3IqA7MAkBbo4x3BPPHEAlxFt4
YsI1UUiTUK3VfEeQ/2ZXnXSw8YVzQb/1bqF9BBHSvDkmxoBHzWlUDW+OQb9DwJpu
4AYR5ywV8hkQuKViyrdvHN9fTRaLwS3+yU+d7a2t38LMHp3AutMe7OosnYpEu8WT
aKXNEQECPU0oOWrwiIDqedV5Aj/B74Eg9+2uhKXNPkaxeP+RyY4WAksLhDAPrJ3a
GuWOpjfPH1tR5r5AfCd5DVN+FlBG/sKQ/Gr2ZWWOZuPOz1kGODoidmSmsUqQfPnH
xjjJc0Is2isoeaE3CaEb88Vs+gcrgX63kxXehnjsN7I/DQ0OHG8Gu9YTl/gs4wS/
9kruImwXbfU4vxFsGIoe1Lu3X2nTHjRwoiwL7byDsk1Hegybj5uyBMLkRVgJ1cJd
mgv7twg++UMibsowY2TOcJ8FZqabA35PuLSHwGOkp8W8dUwwZaq8Grpr22S/Ugg4
5vOo4wGIm9UAXZyrfkTlztAnO0L6CwkzvRYX/jBxynYmR3WHq5VELnZBy/VMdkza
QsfpqA2bU9/m0M/JiXdzzv1csORFoQaNOc19yxJ0KdaE6HxjTuM=
=jnu3
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.