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