[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:de6969fd311307e34904fc1f85603a9d92938974

commit r15-2085-gde6969fd311307e34904fc1f85603a9d92938974
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 17 00:16:59 2024 -0500

    fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]

    Previously effective target fortran_real_c_float128 never
    passes on Power regardless of the default 128 long double
    is ibmlongdouble or ieeelongdouble.  It's due to that TF
    mode is always used for kind 16 real, which has precision
    127, while the node float128_type_node for c_float128 has
    128 type precision, get_real_kind_from_node can't find a
    matching as it only checks gfc_real_kinds[i].mode_precision
    and type precision.

    With changing TFmode/IFmode/KFmode to have the same mode
    precision 128, now fortran_real_c_float12 can pass with
    ieeelongdouble enabled by default and test cases guarded
    with it get tested accordingly.  But with ibmlongdouble
    enabled by default, since TFmode has precision 128 which
    is the same as type precision 128 of float128_type_node,
    get_real_kind_from_node considers kind for TFmode matches
    float128_type_node, but it's wrong as at this time point
    TFmode is with ibm extended format.  So this patch is to
    teach get_real_kind_from_node to check one more field which
    can be differentiable from the underlying real format, it
    can avoid the unexpected matching when there more than one
    modes have the same precisoin.

            PR target/112993

    gcc/fortran/ChangeLog:

            * trans-types.cc (get_real_kind_from_node): Consider the case where
            more than one modes have the same precision.