Re: git: 790a6be5a169 - main - Export various 128 bit long double functions from libgcc_s.so.1

From: Dimitry Andric <dim_at_FreeBSD.org>
Date: Mon, 14 Jun 2021 22:15:42 UTC
On 14 Jun 2021, at 22:38, Mark Millard <marklmi@yahoo.com> wrote:
> 
> Dimitry Andric dim at FreeBSD.org wrote on
> Mon Jun 14 19:17:40 UTC 2021 :
> 
>> The branch main has been updated by dim:
>> 
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=790a6be5a1699291c6da87871426d0c56dedcc89
>> 
>> 
>> commit 790a6be5a1699291c6da87871426d0c56dedcc89
>> Author:     Dimitry Andric <dim at FreeBSD.org>
>> AuthorDate: 2021-06-14 19:17:05 +0000
>> Commit:     Dimitry Andric <dim at FreeBSD.org>
>> CommitDate: 2021-06-14 19:17:05 +0000
>> 
>>    Export various 128 bit long double functions from libgcc_s.so.1
>> 
>>    These were already compiled for some time on aarch64 and riscv, by
>>    including lib/libcompiler_rt/Makefile.inc, but never exported in the
>>    shared library. Since gcc exports these under version GCC_4.6.0, we do
>>    the same.
>> 
>>    This review should replace D11482 for now. For e.g. amd64 more work is
>>    still to be done, as compiler-rt does not seem to support 128 bit long
>>    double math for that architecture.
> 
> Given that "man arch" explicitly reports:
> 
>           Architecture    void *    long double    time_t
> . . .
>           amd64           8         16             8
> . . .
> 
> and also:
> 
>           Architecture    float, double    long double
> . . .
>           amd64           hard             hard, 80 bit
> . . .

Yeah this is a bit confusing, since padding is never mentioned.


> (so there is guaranteed pad involved), would amd64 having 128
> bit long doubles (no pad by default?) be an FreeBSD ABI change,
> possibly needing a discussion on freebsd-arch and
> freebsd-numerics ? (Or may be it happened and I just do not
> remember. Or may be it would take special enabling of the
> alternate ABI's use and not be a default configuration.)
> 
> (i386 only has "12", not "16", for its "80 bit", so 96 bits:
> less pad.)

There's nothing to worry about, the "tf" variants in this update are
only enabled for aarch64 and riscv; see lib/libcompiler_rt/Makefile.inc:

#
# 128-bit quad precision long double support,
# only used on some architectures.
#
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "riscv"
SRCF+=          addtf3
SRCF+=          comparetf2
SRCF+=          divtf3
SRCF+=          extenddftf2
SRCF+=          extendsftf2
SRCF+=          fixtfdi
SRCF+=          fixtfsi
SRCF+=          fixtfti
SRCF+=          fixunstfdi
SRCF+=          fixunstfsi
SRCF+=          fixunstfti
SRCF+=          floatsitf
SRCF+=          floattitf
SRCF+=          floatunsitf
SRCF+=          floatuntitf
SRCF+=          multf3
SRCF+=          subtf3
SRCF+=          trunctfdf2
SRCF+=          trunctfsf2
.endif

I'm sorry to have sowed confusion here, as the commit message was mostly
copy/pasted from the Phabricator review. Please consider the amd64
sentence to be 'cancelled'. :)

-Dimitry