* Please fork soft-fp from libc
@ 2007-06-14 16:11 Uros Bizjak
2007-06-14 16:32 ` Joseph S. Myers
2007-06-14 16:36 ` Joe Buck
0 siblings, 2 replies; 10+ messages in thread
From: Uros Bizjak @ 2007-06-14 16:11 UTC (permalink / raw)
To: GCC
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 16:11 Please fork soft-fp from libc Uros Bizjak
@ 2007-06-14 16:32 ` Joseph S. Myers
2007-06-14 16:36 ` Joe Buck
1 sibling, 0 replies; 10+ messages in thread
From: Joseph S. Myers @ 2007-06-14 16:32 UTC (permalink / raw)
To: Uros Bizjak; +Cc: GCC
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 16:11 Please fork soft-fp from libc Uros Bizjak
2007-06-14 16:32 ` Joseph S. Myers
@ 2007-06-14 16:36 ` Joe Buck
2007-06-14 17:27 ` Richard Guenther
2007-06-14 17:34 ` Jakub Jelinek
1 sibling, 2 replies; 10+ messages in thread
From: Joe Buck @ 2007-06-14 16:36 UTC (permalink / raw)
To: Uros Bizjak; +Cc: GCC
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 16:36 ` Joe Buck
@ 2007-06-14 17:27 ` Richard Guenther
2007-06-14 17:34 ` Jakub Jelinek
1 sibling, 0 replies; 10+ messages in thread
From: Richard Guenther @ 2007-06-14 17:27 UTC (permalink / raw)
To: Joe Buck; +Cc: Uros Bizjak, GCC
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 16:36 ` Joe Buck
2007-06-14 17:27 ` Richard Guenther
@ 2007-06-14 17:34 ` Jakub Jelinek
2007-06-14 18:14 ` Uros Bizjak
1 sibling, 1 reply; 10+ messages in thread
From: Jakub Jelinek @ 2007-06-14 17:34 UTC (permalink / raw)
To: Joe Buck; +Cc: Uros Bizjak, GCC
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 17:34 ` Jakub Jelinek
@ 2007-06-14 18:14 ` Uros Bizjak
2007-06-14 18:17 ` Daniel Jacobowitz
2007-06-14 18:28 ` Jakub Jelinek
0 siblings, 2 replies; 10+ messages in thread
From: Uros Bizjak @ 2007-06-14 18:14 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Joe Buck, GCC
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 18:14 ` Uros Bizjak
@ 2007-06-14 18:17 ` Daniel Jacobowitz
2007-06-14 19:29 ` DJ Delorie
2007-06-14 18:28 ` Jakub Jelinek
1 sibling, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2007-06-14 18:17 UTC (permalink / raw)
To: Uros Bizjak; +Cc: Jakub Jelinek, Joe Buck, GCC
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 18:14 ` Uros Bizjak
2007-06-14 18:17 ` Daniel Jacobowitz
@ 2007-06-14 18:28 ` Jakub Jelinek
2007-06-14 19:04 ` Uros Bizjak
1 sibling, 1 reply; 10+ messages in thread
From: Jakub Jelinek @ 2007-06-14 18:28 UTC (permalink / raw)
To: Uros Bizjak; +Cc: Joe Buck, GCC
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 18:28 ` Jakub Jelinek
@ 2007-06-14 19:04 ` Uros Bizjak
0 siblings, 0 replies; 10+ messages in thread
From: Uros Bizjak @ 2007-06-14 19:04 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Joe Buck, GCC
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Please fork soft-fp from libc
2007-06-14 18:17 ` Daniel Jacobowitz
@ 2007-06-14 19:29 ` DJ Delorie
0 siblings, 0 replies; 10+ messages in thread
From: DJ Delorie @ 2007-06-14 19:29 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gcc
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-06-14 19:29 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-14 16:11 Please fork soft-fp from libc Uros Bizjak
2007-06-14 16:32 ` Joseph S. Myers
2007-06-14 16:36 ` Joe Buck
2007-06-14 17:27 ` Richard Guenther
2007-06-14 17:34 ` Jakub Jelinek
2007-06-14 18:14 ` Uros Bizjak
2007-06-14 18:17 ` Daniel Jacobowitz
2007-06-14 19:29 ` DJ Delorie
2007-06-14 18:28 ` Jakub Jelinek
2007-06-14 19:04 ` Uros Bizjak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).