On Thu, Jun 14, 2007 at 06:10:52PM +0200, Uros Bizjak wrote: > There was no response from libc maintainers about changing the type of > soft-fp compares into CMPtype. This type should be defined to mode(word) > or at least we should be able to redefine it outside the soft-fp, in > target dependent sfp-target.h. As this is major obstacle in further > development (complex numbers) and even in the usability of software FP > as part of gcclib (TFmode compares return wrong values), I propose that > we fork soft-fp from libc. Soft-fp already diverged from libc by > inclusing TImode and TFmode conversions. > > Otherwise, I propose that we disable TFmode support on x86_64 due to > above problems with compares.
The FSF has objected in the past to any discussions of forking glibc. RMS would (I believe) argue that what you're talking about is a glibc bug and glibc should fix it, we shouldn't fork the routine to work around it. After all, the FSF point of view is that GCC and glibc are both part of the GNU project, despite the fact that from the GCC point of value, glibc is only one possible C library, has older and newer versions, etc. Also, we can't take a file from one FSF project and fork it in another without FSF permission, particularly if it involves a license change but even in other cases (because of the way they keep track of assignments). Some think that this is an unnecessary PITA, but that's one of the things we signed up for when we remerged egcs with the FSF, I'm afraid. The SC could discuss this with RMS, but I think your second suggestion might be wise in the short term if there isn't some other workaround. Maybe we can just have RMS annoy the glibc folks until they accept a patch to fix it. But then we have the problem of all those old glibc's that are already out there. So maybe a fork is best after all, and RMS needs to be talked into it. Sigh.
