[Bug libgcc/101489] New: Documentation gives wrong signatures for libgcc float128 routines

[Bug libgcc/101489] New: Documentation gives wrong signatures for libgcc float128 routines

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489

            Bug ID: 101489
           Summary: Documentation gives wrong signatures for libgcc
                    float128 routines
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: harald at gigawatt dot nl
  Target Milestone: ---

At <https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html>,
all functions that take __float128 / _Float128 are declared as taking long
double instead. It is possible this was written back when 128-bit float types
were only available as long double, only on some platforms, so it would have
been correct at that time, but it is no longer correct now that __float128 is
more widely available.

[Bug libgcc/101489] Documentation gives wrong signatures for libgcc float128 routines

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See the "For illustrative purposes, ..." in 
<https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html> which explains the 
conventions for how function prototypes are given in that part of the 
manual.

[Bug libgcc/101489] Documentation gives wrong signatures for libgcc float128 routines

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489

--- Comment #2 from Harald van Dijk <harald at gigawatt dot nl> ---
Ah, thanks for the pointer. Agreed that the signatures are correct based on
that, but they are not exactly clear as they make it impossible to tell apart
the xf and tf cases. Please consider this as an enhancement request, then,
rather than a bug.

My reason for filing this bug was that I noticed something in compiler-rt that
I suspect may be caused by the unclear libgcc documentation. For the most part,
tf implementations are done with long double, but guarded to only apply to
platforms where that is correct. This is fine, it leaves functions undefined on
other platforms but never results in an incorrect definition. There is however
also at least one tf function that is unconditionally done with long double,
which matches the signature in the documentation, but is wrong.