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 Feb 12 10:24, Yaakov Selkowitz wrote: > On 2016-02-12 07:14, Corinna Vinschen wrote: > >On Feb 11 20:27, Yaakov Selkowitz wrote: > >>Any attempt to use isnanf, isinff, or finitef from <ieeefp.h> on > >>platforms other than SPU result in a "lvalue required as unary '&' > >>operand" error. > >> > >> newlib/libc/ > >> * include/ieeefp.h (__ieeefp_isnanf): Remove broken macro. > >> (__ieeefp_isinff, __ieeefp_finitef): Ditto. > > > >This one puzzles me. How is just removing the macros going to help, > >other than avoiding a compiler warning? Wouldn't the right thing to > >do to fix the macros for GCC-5 or provide the functionality otherwise? > > The macros are (supposed to be) just optimized replacements of the > respective function calls. They don't compile, however, and probably didn't > even before GCC 5. They do compile under GCC 4, albeit producing a warning when using -Wall: ie.c:10:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (isnanf (f)) ^ The expression in the macro was valid code once, but apart from GCC and the C standard having moved on, on second glance it suffers a big problem. It assumes sizeof(float)==sizeof(long). It can be made valid again, but how useful is that? So the patch is ok to apply. If somebody complains, we can discuss reinstantiating the macros in a valid way. Thanks, 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] |