This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Please fork soft-fp from libc


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]