On Tue, 2 Jun 2015, Michael Meissner wrote: > On Tue, Jun 02, 2015 at 05:55:10PM +0000, Joseph Myers wrote: > > Is the use of FRACTIONAL_FLOAT_MODE to avoid iterations over > > floating-point modes including these modes when they shouldn't, as > > discussed previously? > > > > If so, how do you deal (in subsequent patches?) with iterations that > > *should* include these modes? In particular, where libgcc uses > > __LIBGCC_<mode>_* macros predefined with -fbuilding-libgcc in an > > interation in c-cppbuiltin.c, how do you handle getting the relevant > > information in libgcc to build applicable libgcc functions for these > > modes? (I'm presuming that you do want complex arithmetic to work for > > both 128-bit types, for example, although you won't want them to be used > > for intermediate conversions in libgcc operations on other types.) > > I have a catch-22 situation. We can't really do the glibc stuff until we have > the compiler. Right now, I use a makefile on libgcc/config/rs6000 that copies > the various TF files and modifies it for KF files.
The functions I'm mainly thinking of are the libgcc2.c ones rather than the soft-fp ones (powi?f2 mul?c3 div?c3). > After we get the basic support in, we can then start tackling glibc. It may > be > when we get to doing the work in glibc itself, we will need to make further > modifications. However, in order for the glibc people to start, I need the > basic support in the compiler in the tree. It's not obvious what glibc support should look like in the absence of a change to the default for long double; that would require discussion on libc-alpha at an early stage to establish a consensus on the design. libquadmath support should be easy (given working compiler / libgcc support). But if you want more than libquadmath support, there are several possible forms for support in glibc proper depending on e.g. whether you want to support a -m option to change long double, or using the functions via the __float128 type name and separate names for the functions, or both. -- Joseph S. Myers jos...@codesourcery.com
