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