Please fork soft-fp from libc

Please fork soft-fp from libc

[Uros Bizjak]

Hello!

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.

Thanks for considering this,
Uros.

Re: Please fork soft-fp from libc

[Joseph S. Myers]

On Thu, 14 Jun 2007, 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

Take that matter with the glibc maintainers directly to RMS.

> 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.

Take that proposal directly to RMS.  Forking shared files is not a matter 
for the gcc list.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Please fork soft-fp from libc

[Joe Buck]

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.

Re: Please fork soft-fp from libc

[Richard Guenther]

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.

Re: Please fork soft-fp from libc

[Jakub Jelinek]

On Thu, Jun 14, 2007 at 09:36:46AM -0700, Joe Buck wrote:
> 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.

It can hardly be considered a glibc bug when GCC changed this incompatibly
a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
all architectures glibc cares about).

That said, as none of the routines in question
({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
use glibc soft-fp code, I guess using CMPtype in those routines doesn't
hurt.  I believe --without-fp ppc support in ports is 32-bit only as well
and therefore doesn't care either.
But certainly it must not be defined to int __attribute__ ((mode (word))),
because Andreas Krebbel is actively trying to get rid of that attribute.
Each sfp-machine.h can define CMPtype instead.

	Jakub

Re: Please fork soft-fp from libc

[Uros Bizjak]

Jakub Jelinek wrote:
> On Thu, Jun 14, 2007 at 09:36:46AM -0700, Joe Buck wrote:
>   
>> 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.
>>     
>
> It can hardly be considered a glibc bug when GCC changed this incompatibly
> a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
> all architectures glibc cares about).
>
> That said, as none of the routines in question
> ({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
> use glibc soft-fp code, I guess using CMPtype in those routines doesn't
> hurt.  I believe --without-fp ppc support in ports is 32-bit only as well
> and therefore doesn't care either.
> But certainly it must not be defined to int __attribute__ ((mode (word))),
> because Andreas Krebbel is actively trying to get rid of that attribute.
> Each sfp-machine.h can define CMPtype instead.
>   
I belive that by changing mentioned typedef line of soft-fp.h into

#ifndef CMPtype
#define CMPtype         int
#endif

would satisfy everybody. Is this acceptable for glibc?

Thanks,
Uros.

Re: Please fork soft-fp from libc

[Daniel Jacobowitz]

On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
> > It can hardly be considered a glibc bug when GCC changed this incompatibly
> > a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
> > all architectures glibc cares about).
> >
> > That said, as none of the routines in question
> > ({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
> > use glibc soft-fp code,

Could anyone explain why this change was made?  It seems like SItype
would be sufficient everywhere, and I can't see any obvious reason it
would be slower.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Please fork soft-fp from libc

[Jakub Jelinek]

On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
> I belive that by changing mentioned typedef line of soft-fp.h into
> 
> #ifndef CMPtype
> #define CMPtype         int
> #endif
> 
> would satisfy everybody. Is this acceptable for glibc?

Yes.
Though, please use CMPtype not only for return types of the functions, but
also for the type of r variables.

	Jakub

Re: Please fork soft-fp from libc

[Uros Bizjak]

Jakub Jelinek wrote:
> On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
>   
>> I belive that by changing mentioned typedef line of soft-fp.h into
>>
>> #ifndef CMPtype
>> #define CMPtype         int
>> #endif
>>
>> would satisfy everybody. Is this acceptable for glibc?
>>     
>
> Yes.
> Though, please use CMPtype not only for return types of the functions, but
> also for the type of r variables.
>   

Thanks. I have changed the patch as requested, and it was just sent to 
glibc-alpha@.

Thanks again for your help to resolve this problem,
Uros.

Re: Please fork soft-fp from libc

[DJ Delorie]

Daniel Jacobowitz <drow@false.org> writes:
> It seems like SItype would be sufficient everywhere, and I can't see
> any obvious reason it would be slower.

What about 16-bit targets?