svn commit: r307231 - head/lib/libgcc_s
Ed Maste
emaste at freebsd.org
Fri Oct 14 02:06:30 UTC 2016
Hi Bruce, thank you for the detailed response.
On 14 October 2016 at 01:53, Bruce Evans <brde at optusnet.com.au> wrote:
>> compiler-rt's complex division support routines contain calls to
>> compiler builtins such as `__builtin_scalbnl`. Unfortunately Clang
>> turns these back into a call to `scalbnl`.
>
> gcc-4.2 has the same bug.
Oh, interesting. Do you know off hand if it's resolved in later GCC?
It seems particularly unfortunate for the compiler to report (by
whatever mechanism) that a builtin exists, and then just turn that
builtin into a library call.
>> For now link libm's C version of the required support routines.
>
> Even libm doesn't use these in some cases. i386 mostly uses asm
> versions. Hopefully the rt division routines don't need to be efficient
> because they are rarely called.
Most likely I'll switch to the asm versions across suitable
architectures in a subsequent change, mirroring the choices made in
libm. I just wanted to get a version in, to enable further testing
(ports exp-runs, etc.) of this libunwind / compiler-rt combination.
[Details about specific groups of functions omitted -- I'll try to
take a look at these later.]
> libcompiler_rt.a now on amd64 now has the following namespace bugs:
>
> U compilerrt_abort_impl
> U fflush
> U fprintf
> U mprotect
> U sysconf
> U fmaxl
> U logbl
> U scalbnl
> U logbf
> U scalbnf
> U logb
> U scalbn
> U abort
>
> These are bugs since division must be available with -ffreestanding and
> the freestanding library shouldn't have to reimplement it.
Yes, these libcompiler_rt.a issues seem rather surprising to me, but
presumably they aren't causing much of an issue in practice in the
static lib. In any case, my hope is that once I try disentangling
these libraries I can take a look at these issues across the set of
libraries (libcompiler_rt.a aka libgcc.a, libgcc_eh.a, libgcc_s.so).
More information about the svn-src-all
mailing list