* arm fenv support - static inline of methods @ 2020-05-13 14:11 Joel Sherrill 2020-05-13 18:17 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Joel Sherrill @ 2020-05-13 14:11 UTC (permalink / raw) To: Newlib, Eshan Dhawan Hi Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX methods to RTEMS and newlib if appropriate. He is currently looking at adding more fenv.h implementations. The FreeBSD implementation of arm fenv.h has static inlines for all the methods in sys/fenv.h. Is this OK? Or should they be turned into real bodies in a C file? --joel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods 2020-05-13 14:11 arm fenv support - static inline of methods Joel Sherrill @ 2020-05-13 18:17 ` Brian Inglis 2020-05-13 18:22 ` Joel Sherrill 2020-05-13 21:03 ` Richard Damon 0 siblings, 2 replies; 6+ messages in thread From: Brian Inglis @ 2020-05-13 18:17 UTC (permalink / raw) To: newlib On 2020-05-13 08:11, Joel Sherrill wrote: > Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX > methods to RTEMS and newlib if appropriate. He is currently looking at > adding more > fenv.h implementations. > > The FreeBSD implementation of arm fenv.h has static inlines for all the > methods in sys/fenv.h. Is this OK? Or should they be turned into real > bodies in a C file? Don't all functions need to be provided as linkable implementations for cases where they are invoked using their address directly or indirectly, unless the standards agree they don't need to be? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods 2020-05-13 18:17 ` Brian Inglis @ 2020-05-13 18:22 ` Joel Sherrill 2020-05-13 18:36 ` Brian Inglis 2020-05-13 21:03 ` Richard Damon 1 sibling, 1 reply; 6+ messages in thread From: Joel Sherrill @ 2020-05-13 18:22 UTC (permalink / raw) To: Newlib On Wed, May 13, 2020 at 1:17 PM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote: > On 2020-05-13 08:11, Joel Sherrill wrote: > > > Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX > > methods to RTEMS and newlib if appropriate. He is currently looking at > > adding more > > fenv.h implementations. > > > > The FreeBSD implementation of arm fenv.h has static inlines for all the > > methods in sys/fenv.h. Is this OK? Or should they be turned into real > > bodies in a C file? > > Don't all functions need to be provided as linkable implementations for > cases > where they are invoked using their address directly or indirectly, unless > the > standards agree they don't need to be? > That's what I think also but that's not how FreeBSD has implemented it. IMO the static inline implementations from them need to move to .c files. --joel > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods 2020-05-13 18:22 ` Joel Sherrill @ 2020-05-13 18:36 ` Brian Inglis 2020-05-13 19:14 ` Joel Sherrill 0 siblings, 1 reply; 6+ messages in thread From: Brian Inglis @ 2020-05-13 18:36 UTC (permalink / raw) To: newlib On 2020-05-13 12:22, Joel Sherrill wrote: > On Wed, May 13, 2020 at 1:17 PM, Brian Inglis wrote: >> On 2020-05-13 08:11, Joel Sherrill wrote: >>> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX >>> methods to RTEMS and newlib if appropriate. He is currently looking at >>> adding more >>> fenv.h implementations. >>> >>> The FreeBSD implementation of arm fenv.h has static inlines for all the >>> methods in sys/fenv.h. Is this OK? Or should they be turned into real >>> bodies in a C file? >> Don't all functions need to be provided as linkable implementations for >> cases where they are invoked using their address directly or indirectly, >> unless the standards agree they don't need to be? > That's what I think also but that's not how FreeBSD has implemented it. > IMO the static inline implementations from them need to move to .c files. I'm pretty sure I've seen somewhere in the sources, that the library has a standard approach for doing this, as most libraries do for such common cases. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods 2020-05-13 18:36 ` Brian Inglis @ 2020-05-13 19:14 ` Joel Sherrill 0 siblings, 0 replies; 6+ messages in thread From: Joel Sherrill @ 2020-05-13 19:14 UTC (permalink / raw) To: Newlib On Wed, May 13, 2020 at 1:36 PM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote: > > On 2020-05-13 12:22, Joel Sherrill wrote: > > On Wed, May 13, 2020 at 1:17 PM, Brian Inglis wrote: > >> On 2020-05-13 08:11, Joel Sherrill wrote: > > >>> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX > >>> methods to RTEMS and newlib if appropriate. He is currently looking at > >>> adding more > >>> fenv.h implementations. > >>> > >>> The FreeBSD implementation of arm fenv.h has static inlines for all the > >>> methods in sys/fenv.h. Is this OK? Or should they be turned into real > >>> bodies in a C file? > > >> Don't all functions need to be provided as linkable implementations for > >> cases where they are invoked using their address directly or indirectly, > >> unless the standards agree they don't need to be? > > > That's what I think also but that's not how FreeBSD has implemented it. > > IMO the static inline implementations from them need to move to .c files. > > I'm pretty sure I've seen somewhere in the sources, that the library has a > standard approach for doing this, as most libraries do for such common > cases. > Thanks for saying that. It just occurred triggered me to realize that this in the header file: #ifndef __fenv_static #define __fenv_static static #endif All we need is an arm fenv.c which does this #define __fenv_static #include <fenv.h> Then magically, we have methods (I think). And empty files for every fenv source file named for a method since all the methods are in one file. Thank you. I think that's enough to let me help Eshan through this. --joel -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods 2020-05-13 18:17 ` Brian Inglis 2020-05-13 18:22 ` Joel Sherrill @ 2020-05-13 21:03 ` Richard Damon 1 sibling, 0 replies; 6+ messages in thread From: Richard Damon @ 2020-05-13 21:03 UTC (permalink / raw) To: newlib On 5/13/20 2:17 PM, Brian Inglis wrote: > On 2020-05-13 08:11, Joel Sherrill wrote: > >> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX >> methods to RTEMS and newlib if appropriate. He is currently looking at >> adding more >> fenv.h implementations. >> >> The FreeBSD implementation of arm fenv.h has static inlines for all the >> methods in sys/fenv.h. Is this OK? Or should they be turned into real >> bodies in a C file? > Don't all functions need to be provided as linkable implementations for cases > where they are invoked using their address directly or indirectly, unless the > standards agree they don't need to be? > But you CAN take the address of a static inline function, and then call through that address. Taking the address will force the compiler to generate an out of line copy to take the address of it. What this doesn't allow is manually providing a prototype per the standard and calling it, but I am not sure that is officially required to be supported in the standard. -- Richard Damon ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-13 21:03 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-13 14:11 arm fenv support - static inline of methods Joel Sherrill 2020-05-13 18:17 ` Brian Inglis 2020-05-13 18:22 ` Joel Sherrill 2020-05-13 18:36 ` Brian Inglis 2020-05-13 19:14 ` Joel Sherrill 2020-05-13 21:03 ` Richard Damon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).