NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: toolchain/57022: programs built with aarch64 toolchain want __fixdfti, which doesn't exist



The following reply was made to PR toolchain/57022; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: nia%pkgsrc.org@localhost
Cc: 
Subject: Re: toolchain/57022: programs built with aarch64 toolchain want __fixdfti, which doesn't exist
Date: Sat, 24 Sep 2022 10:38:22 +0000

 > Date: Sat, 24 Sep 2022 09:00:01 +0000 (UTC)
 > From: nia%pkgsrc.org@localhost
 >=20
 > UnifiedSource-f2e18ffc-13.cpp:(.text+0x3fd0): undefined reference to `__f=
 ixdfti'
 >=20
 > This is a softfloat function for converting a double to a signed 64-bit
 > int, rounding toward zero. It seems like something that should not be
 > required on aarch64?
 > >How-To-Repeat:
 > presumably write code that converts a double to a singed 64-bit int
 
 This is actually for converting double (IEEE 754 binary64) to
 int128_t.
 
 Example:
 
         __int128_t
         foo(double x)
         {
                 return x;
         }
 
         0000000000000000 <foo>:
            0:	a9bf7bfd 	stp	x29, x30, [sp, #-16]!
            4:	910003fd 	mov	x29, sp
            8:	94000000 	bl	0 <__fixdfti>
                                 8: R_AARCH64_CALL26	__fixdfti
            c:	a8c17bfd 	ldp	x29, x30, [sp], #16
           10:	d65f03c0 	ret
 
 It's unclear to me whether this function is supposed to come from
 libgcc or compiler-rt.
 
 On x86, it comes from libgcc, via _fixdfdi.c -- note: di, not ti.
 Somehow _fixdfdi.c, which is just
 
         #define L_fixdfdi
         #include <libgcc2.c>,
 
 manages to define only __fixdfti and not __fixdfdi, via
 
         dist/libgcc/libgcc2.h:#define __fixdfdi __NDW(fixdf,)
 
 where I think we're catching the definition
 
         dist/libgcc/libgcc2.h:#define __NDW(a,b)      __ ## a ## ti ## b
 
 However, on aarch64 (and coldfire and earm and mips64 and mipsn64),
 _fixdfdi.c is excluded from libgcc by the following fragment in
 external/gpl3/gcc/lib/libgcc/Makefile.inc:
 
         .if ${LIBGCC_MACHINE_ARCH} !=3D "coldfire" && \
             empty(LIBGCC_MACHINE_ARCH:Mearm*) && \
             empty(LIBGCC_MACHINE_ARCH:Maarch64*) && \
             empty(LIBGCC_MACHINE_ARCH:Mmips64*) && \
             empty(LIBGCC_MACHINE_ARCH:Mmipsn64*)
 
         EXTRA_FUNC_SIZES=3D	sf df xf
 
         .if ${LIBGCC_MACHINE_ARCH} !=3D "x86_64" && \
             ${LIBGCC_MACHINE_ARCH} !=3D "i386" && \
             ${LIBGCC_MACHINE_ARCH} !=3D "ia64"
         EXTRA_FUNC_SIZES+=3D	tf
         .endif
 
         # non swfloat versions=20
         .for _p in _fix _fixuns
         . for _m in ${EXTRA_FUNC_SIZES}
         LIB2FUNCS_ALL+=3D	${_p}${_m}di
         . endfor
         .endfor
 
 In libc's compiler-rt, fixdfti.c is excluded everywhere by this
 fragment in lib/libc/compiler_rt/Makefile.inc:
 
         # only used for machines using IEEE 754 floating point formats
         .if ${MACHINE_ARCH} !=3D "vax"
 
         .if 0
         # Conflicts with soft-float
         GENERIC_SRCS+=3D \
                 comparedf2.c \
                 ...
                 fixdfti.c \
                 ...
         .endif
 
 So one of these needs to be wired up, it seems -- either libgcc or
 compiler-rt.  Which one?  I have no idea what to prefer.
 


Home | Main Index | Thread Index | Old Index