On Tue, Jun 2, 2015 at 4:14 PM, Joseph Myers <jos...@codesourcery.com> wrote: > 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.
Sounds like a fun night at a Czech pub during GNU Cauldron. - David
