Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 01:20:29PM +1000, Hasjim Williams wrote: Suffice to say, it will compile, but when you try to run it, and your program tries to do the libcall to the sqrt function it will segfault, because there is no libcall sqrt defined. As far as I can tell, sqrt and div are the only major opcodes that are needed (for ieee754 glibc --with-fp) that aren't implemented in MaverickCrunch. I'm going to keep asking until I get something we can work with... you're reporting a bug in the compiler, so we need a test case and the exact error message. What is generating any kind of sqrt libcall? There is nothing in GCC to call __aeabi_sqrt, which AFAIK does not exist. -- Daniel Jacobowitz CodeSourcery
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, 15 Apr 2008 09:15:45 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
I'm going to keep asking until I get something we can work
with... you're reporting a bug in the compiler, so we need a test case
and the exact error message. What is generating any kind of sqrt
libcall? There is nothing in GCC to call __aeabi_sqrt, which AFAIK
does not exist.
gcc shouldn't call __aeabi_sqrt, since it doesn't exist. It could
however try to do a libcall through the optab to sqrtsf2, since
sqrt_optab does exist in optabs.h/c and genopinit.c ...
Ok, to try and test this out, I added this patch to gcc, and recompiled
gcc glibc --with-fp for crunch:
--- gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 17:59:35.0
+1000
+++ gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 18:02:08.0
+1000
@@ -3100,6 +3100,22 @@
TARGET_ARM TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP)
)
+(define_expand sqrtsf2_soft_insn
+ [(set (match_operand:SF 0 s_register_operand )
+ (sqrt:SF (match_operand:SF 1 s_register_operand )))]
+ TARGET_ARM !(TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP))
+ {
+ FAIL;
+ })
+
+(define_expand sqrtdf2_soft_insn
+ [(set (match_operand:DF 0 s_register_operand )
+ (sqrt:DF (match_operand:DF 1 s_register_operand )))]
+ TARGET_ARM !(TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP))
+ {
+ FAIL;
+ })
+
(define_insn_and_split one_cmpldi2
[(set (match_operand:DI 0 s_register_operand =r,r)
(not:DI (match_operand:DI 1 s_register_operand ?r,0)))]
I was expecting it to fail since now gcc shouldn't be able to expand
that operation. I double check glibc config.status, and with_fp=yes.
So, I'm not sure how glibc is doing it's sqrt routines on arm. In that
case I suspect that glibc doesn't call sqrt for VFP or FPA, then, and
you were right in your first e-mail.
glibc uses its own internal sqrt function, rather than the
sqrtsf2/sqrtdf2 opcode, even on FPA or VFP.
In any case if you want a test, then something like
gcc/testsuite/gcc.dg/arm-vfp1.c is enough (of course with different
dejagnu lines, e.g. dg-final scan-assembler lines) ...
I still think something like the above patch needs to be added to gcc,
just to ensure that the sqrtsf2 / sqrtdf2 libcall never happens, and an
error happens at compile time rather than runtime. In the future glibc,
uclibc or some standalone function could make use of the gcc sqrt,
rather than the glibc sqrt.
Anyway, I misunderstood how the toolchain gets assembled and I would
appreciate it someone could point out where the sqrt function is in
glibc, on arm.
Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ???
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Wed, Apr 16, 2008 at 09:18:07AM +1000, Hasjim Williams wrote: glibc uses its own internal sqrt function, rather than the sqrtsf2/sqrtdf2 opcode, even on FPA or VFP. Always. That's how it is supposed to work; the expander allows GCC to optimize sqrt operations inline, for architectures where it is profitable to do so. But the backing function remains sqrt (sqrtf, sqrtl). The implementation of that lives in the C library and is not dependent on GCC for the body. Anyway, I misunderstood how the toolchain gets assembled and I would appreciate it someone could point out where the sqrt function is in glibc, on arm. Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ??? I don't know for sure, but it seems likely. Build glibc with debug info and step through it? -- Daniel Jacobowitz CodeSourcery
[ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
Hello all, I've been working on MaverickCrunch support in gcc, and could never get a completely working glibc (with-fp), since there is no soft-float sqrt libcall function. This is a big problem for MaverickCrunch as there are no hard div or sqrt opcodes. It seems that this is the only other thing that is missing to let glibc be compiled with-fp for soft float arm, too. Is it possible to add these functions to ieee754-sf.S and ieee754-df.S ??? There is of course a c implementation in glibc/soft-fp but I don't know of any arm assembly implementation... I know that ARM IHI 0043A doesn't specific this as part of the EABI, but perhaps it needs to be added? Thanks
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote: Hello all, I've been working on MaverickCrunch support in gcc, and could never get a completely working glibc (with-fp), since there is no soft-float sqrt libcall function. This is a big problem for MaverickCrunch as there are no hard div or sqrt opcodes. It seems that this is the only other thing that is missing to let glibc be compiled with-fp for soft float arm, too. Is it possible to add these functions to ieee754-sf.S and ieee754-df.S ??? There is of course a c implementation in glibc/soft-fp but I don't know of any arm assembly implementation... I know that ARM IHI 0043A doesn't specific this as part of the EABI, but perhaps it needs to be added? Can you be more specific about the actual problem? I don't see why there needs to be an __aeabi_sqrt; sqrt is a function in libm. -- Daniel Jacobowitz CodeSourcery
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Mon, 14 Apr 2008 22:41:36 -0400, Daniel Jacobowitz [EMAIL PROTECTED] said: On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote: Hello all, I've been working on MaverickCrunch support in gcc, and could never get a completely working glibc (with-fp), since there is no soft-float sqrt libcall function. This is a big problem for MaverickCrunch as there are no hard div or sqrt opcodes. Can you be more specific about the actual problem? I don't see why there needs to be an __aeabi_sqrt; sqrt is a function in libm. Both FPA and VFP coprocessors implement sqrt opcodes: arm.md: (define_expand sqrtsf2 [(set (match_operand:SF 0 s_register_operand ) (sqrt:SF (match_operand:SF 1 s_register_operand )))] TARGET_32BIT TARGET_HARD_FLOAT (TARGET_FPA || TARGET_VFP) ) fpa.md: (define_insn *sqrtsf2_fpa [(set (match_operand:SF 0 s_register_operand =f) (sqrt:SF (match_operand:SF 1 s_register_operand f)))] TARGET_32BIT TARGET_HARD_FLOAT TARGET_FPA sqt%?s\\t%0, %1 [(set_attr type float_em) (set_attr predicable yes)] ) vfp.md: (define_insn *sqrtsf2_vfp [(set (match_operand:SF0 s_register_operand =t) (sqrt:SF (match_operand:SF 1 s_register_operand t)))] TARGET_32BIT TARGET_HARD_FLOAT TARGET_VFP fsqrts%?\\t%0, %1 [(set_attr predicable yes) (set_attr type fdivs)] ) Now, when you build glibc configured --with-fp, you won't use the generic glibc/soft-fp functions, only those in gcc, i.e. the above. Only if you configure glibc --without-fp will it not use the above opcodes, but the soft-fp sqrt etc.
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote: Both FPA and VFP coprocessors implement sqrt opcodes: So? Glibc does not rely on that. I've been building soft-float versions of glibc for non-Crunch targets for scarily close to a decade now, so this is clearly not the problem :-) Please say what actual error you've encountered. -- Daniel Jacobowitz CodeSourcery
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Mon, 14 Apr 2008 23:09:00 -0400, Daniel Jacobowitz [EMAIL PROTECTED] said: On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote: Both FPA and VFP coprocessors implement sqrt opcodes: So? Glibc does not rely on that. I've been building soft-float versions of glibc for non-Crunch targets for scarily close to a decade now, so this is clearly not the problem :-) Please say what actual error you've encountered. Of course you can build glibc and have it work correctly, as you are configuring glibc --without-fp. Try building glibc --with-fp and seeing whether it works. Suffice to say, it will compile, but when you try to run it, and your program tries to do the libcall to the sqrt function it will segfault, because there is no libcall sqrt defined. As far as I can tell, sqrt and div are the only major opcodes that are needed (for ieee754 glibc --with-fp) that aren't implemented in MaverickCrunch.
