Please fork soft-fp from libc

Richard Guenther richard.guenther@gmail.com
Thu Jun 14 17:27:00 GMT 2007


On 6/14/07, Joe Buck <Joe.Buck@synopsys.com> wrote:
> 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.

Reminds me of forking glibc libm and the libgcc-math discussion
that's still on hold from RMS side.

Richard.



More information about the Gcc mailing list