This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |