Displaying 4 results from an estimated 4 matches for "lib1asmfuncs".
2007 Oct 20
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
...e (see crtstuff.c) which
Index: gcc/config/arm/t-linux
===================================================================
--- gcc/config/arm/t-linux (revision 42922)
+++ gcc/config/arm/t-linux (working copy)
@@ -4,7 +4,10 @@
LIBGCC2_DEBUG_CFLAGS = -g0
LIB1ASMSRC = arm/lib1funcs.asm
-LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx
+LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx \
+ _negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi
_fixunsdfsi \
+ _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \
+ _fixsfsi _fixunssfsi
# MULTILI...
2007 Oct 19
0
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote:
> hi,
>
> i'm trying to make some experiments with the ARM backend (llvm 2.1)
> and
> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux.
>
> however, the llvm-gcc frontend seems to cause troubles with single
> precision floating point values, i.e., they are not converted
> correctly
> to the
2007 Oct 22
0
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
...ig/arm/t-linux
> ===================================================================
> --- gcc/config/arm/t-linux (revision 42922)
> +++ gcc/config/arm/t-linux (working copy)
> @@ -4,7 +4,10 @@
> LIBGCC2_DEBUG_CFLAGS = -g0
>
> LIB1ASMSRC = arm/lib1funcs.asm
> -LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx
> +LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx \
> + _negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi
> _fixunsdfsi \
> + _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \
> + _fixsfsi...
2007 Oct 19
3
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
hi,
i'm trying to make some experiments with the ARM backend (llvm 2.1) and
therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux.
however, the llvm-gcc frontend seems to cause troubles with single
precision floating point values, i.e., they are not converted correctly
to the particular target format (double precision works as expected).
it seems the problem is related to