On Tue, 4 Feb 2014, Richard Sandiford wrote: > So here I just provide simple C functions for each operation that has > hard-float support. We can then restrict the softfp stuff to functions > that really do need softfp support, meaning that softfp_exclude_libgcc2 := n > should always be OK. As an added bonus it reduces the footprint of > libgcc_s.so > on hard-float targets.
Simple C functions are indeed the best thing for cases where the functions are only part of the ABI at all because of historical accident of it being hard to build fp-bit only for soft-float multilibs. But they're also useful for more than just MIPS - 32-bit powerpc hard float could use them as well, for example (it seems likely there are other cases, but powerpc is one I know about). So I think the implementation and a makefile fragment for them should be outside config/mips, although targets may need to configure exactly which functions to build from this set. (For example, e500v1 would want simple C functions for SFmode but soft-fp for DFmode, and for __unordsf2; e500v2 would want soft-fp for __unordsf2 and __unorddf2 but otherwise simple C functions. I don't think the initial patch needs to build out the full configurability, as long as the files are in the right place, outside config/mips.) A patch putting the files in an architecture-independent place should probably then be reviewed by Ian as libgcc maintainer. > +#elif defined (OP_eq2) > +int FUNC (TYPE x, TYPE y) { return x == y; } > +#elif defined (OP_ne2) > +int FUNC (TYPE x, TYPE y) { return x != y; } > +#elif defined (OP_ge2) > +int FUNC (TYPE x, TYPE y) { return x >= y; } > +#elif defined (OP_gt2) > +int FUNC (TYPE x, TYPE y) { return x > y; } > +#elif defined (OP_le2) > +int FUNC (TYPE x, TYPE y) { return x <= y; } > +#elif defined (OP_lt2) > +int FUNC (TYPE x, TYPE y) { return x < y; } That's not the semantics of the comparison functions. They return an integer value that can be compared to 0 with the original operation to get the final result, rather than returning the result of the comparison directly. See libgcc.texi. -- Joseph S. Myers jos...@codesourcery.com