[Bug c++/85518] ICE mangling _FloatN types

[Bug c++/85518] ICE mangling _FloatN types

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The PR106652 WIP patch should fix this.

[Bug c++/85518] ICE mangling _FloatN types

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually not fully.  While it adds mangling for _Float{16,32,64,128}, it
doesn't add mangling for _Float{32,64,128}x. 
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling doesn't have
anything for those and there is no need to add _Float{32,64,128}x support to
the C++ FE right now.
Perhaps the *x suffixed builtins should be C only?

[Bug c++/85518] ICE mangling _FloatN types

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r13-2887-gb04208895fed34171eac6bafb60c90048eb1cb0c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 27 08:04:06 2022 +0200

    c++: Implement P1467R9 - Extended floating-point types and standard names
compiler part except for bfloat16 [PR106652]

    The following patch implements the compiler part of C++23
    P1467R9 - Extended floating-point types and standard names compiler part
    by introducing _Float{16,32,64,128} as keywords and builtin types
    like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
    mangling.
    It also introduces _Float{32,64,128}x for C++ with the
    https://github.com/itanium-cxx-abi/cxx-abi/pull/147
    proposed mangling of DF{32,64,128}x.
    The patch doesn't add anything for bfloat16_t support, as right now
    __bf16 type refuses all conversions and arithmetic operations.
    The patch wants to keep backwards compatibility with how __float128 has
    been handled in C++ before, both for mangling and behavior in binary
    operations, overload resolution etc.  So, there are some backend changes
    where for C __float128 and _Float128 are the same type (float128_type_node
    and float128t_type_node are the same pointer), but for C++ they are
distinct
    types which mangle differently and _Float128 is treated as extended
    floating-point type while __float128 is treated as non-standard floating
    point type.  The various C++23 changes about how floating-point types
    are changed are actually implemented as written in the spec only if at
least
    one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx
are
    also treated as extended floating-point types) and kept previous behavior
    otherwise.  For float/double/long double the rules are actually written
that
    they behave the same as before.
    There is some backwards incompatibility at least on x86 regarding _Float16,
    because that type was already used by that name and with the DF16_ mangling
    (but only since GCC 12 and I think it isn't that widely used in the wild
    yet).  E.g. config/i386/avx512fp16intrin.h shows the issues, where
    in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
    argument, but with the changes that is not possible anymore, one needs
    to either use 0.0f16 or (_Float16) 0.0f.
    We have also a problem with glibc headers, where since glibc 2.27
    math.h and complex.h aren't compilable with these changes.  One gets
    errors like:
    In file included from /usr/include/math.h:43,
                     from abc.c:1:
    /usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
       86 | typedef __float128 _Float128;
          |         ^~~~~~~~~~
    /usr/include/bits/floatn.h:86:20: error: declaration does not declare
anything [-fpermissive]
       86 | typedef __float128 _Float128;
          |                    ^~~~~~~~~
    In file included from /usr/include/bits/floatn.h:119:
    /usr/include/bits/floatn-common.h:214:9: error: multiple types in one
declaration
      214 | typedef float _Float32;
          |         ^~~~~
    /usr/include/bits/floatn-common.h:214:15: error: declaration does not
declare anything [-fpermissive]
      214 | typedef float _Float32;
          |               ^~~~~~~~
    /usr/include/bits/floatn-common.h:251:9: error: multiple types in one
declaration
      251 | typedef double _Float64;
          |         ^~~~~~
    /usr/include/bits/floatn-common.h:251:16: error: declaration does not
declare anything [-fpermissive]
      251 | typedef double _Float64;
          |                ^~~~~~~~
    This is from snippets like:
     /* The remaining of this file provides support for older compilers.  */
     # if __HAVE_FLOAT128

     /* The type _Float128 exists only since GCC 7.0.  */
     #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
     typedef __float128 _Float128;
     #  endif
    where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x}
support nor
    {f,F}{16,32,64,128}{,x} literal suffixes nor _Complex
_Float{16,32,64,128,32x,64x,128x}.
    The patch fixincludes this for now and hopefully if this is committed, then
    glibc can change those.  The patch changes those
     #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
    conditions to
     #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13,
0))
    Another thing is mangling, as said above, Itanium C++ ABI specifies
    DF <number> _ as _Float{16,32,64,128} mangling, but GCC was implementing
    a mangling incompatible with that starting with DF for fixed point types.
    Fixed point was never supported in C++ though, I believe the reason why
    the mangling has been added was that due to a bug it would leak into the
    C++ FE through decltype (0.0r) etc.  But that has been shortly after the
    mangling was added fixed (I think in the same GCC release cycle), so we
    now reject 0.0r etc. in C++.  If we ever need the fixed point mangling,
    I think it can be readded but better with a different prefix so that it
    doesn't conflict with the published standard manglings.  So, this patch
    also kills the fixed point mangling and implements the DF <number> _
    demangling.
    The patch predefines __STDCPP_FLOAT{16,32,64,128}_T__ macros when
    those types are available, but only for C++23, while the underlying types
    are available in C++98 and later including the {f,F}{16,32,64,128} literal
    suffixes (but those with a pedwarn for C++20 and earlier).  My
understanding
    is that it needs to be predefined by the compiler, on the other side
    predefining even for older modes when <stdfloat> is a new C++23 header
    would be weird.  One can find out if _Float{16,32,64,128,32x,64x,128x} is
    supported in C++ by
    __GNUC__ >= 13 && defined(__FLT{16,32,64,128,32X,64X,128X}_MANT_DIG__)
    (but that doesn't work well with older G++ 13 snapshots).

    As for std::bfloat16_t, three targets (aarch64, arm and x86) apparently
    "support" __bf16 type which has the bfloat16 format, but isn't really
    usable, e.g. {aarch64,arm,ix86}_invalid_conversion disallow any conversions
    from or to type with BFmode, {aarch64,arm,ix86}_invalid_unary_op disallows
    any unary operations on those except for ADDR_EXPR and
    {aarch64,arm,ix86}_invalid_binary_op disallows any binary operation on
    those.  So, I think we satisfy:
    "If the implementation supports an extended floating-point type with the
    properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2, storage
    width in bits (k) of 16, precision in bits (p) of 8, maximum exponent
(emax)
    of 127, and exponent field width in bits (w) of 8, then the typedef-name
    std::bfloat16_t is defined in the header <stdfloat> and names such a type,
    the macro __STDCPP_BFLOAT16_T__ is defined, and the floating-point literal
    suffixes bf16 and BF16 are supported."
    because we don't really support those right now.

    2022-09-27  Jakub Jelinek  <jakub@redhat.com>

            PR c++/106652
            PR c++/85518
    gcc/
            * tree-core.h (enum tree_index): Add TI_FLOAT128T_TYPE
            enumerator.
            * tree.h (float128t_type_node): Define.
            * tree.cc (build_common_tree_nodes): Initialize
float128t_type_node.
            * builtins.def (DEF_FLOATN_BUILTIN): Adjust comment now that
            _Float<N> is supported in C++ too.
            * config/i386/i386.cc (ix86_mangle_type): Only mangle as "g"
            float128t_type_node.
            * config/i386/i386-builtins.cc (ix86_init_builtin_types): Use
            float128t_type_node for __float128 instead of float128_type_node
            and create it if NULL.
            * config/i386/avx512fp16intrin.h (_mm_setzero_ph,
_mm256_setzero_ph,
            _mm512_setzero_ph, _mm_set_sh, _mm_load_sh): Use 0.0f16 instead of
            0.0f.
            * config/ia64/ia64.cc (ia64_init_builtins): Use
            float128t_type_node for __float128 instead of float128_type_node
            and create it if NULL.
            * config/rs6000/rs6000-c.cc (is_float128_p): Also return true
            for float128t_type_node if non-NULL.
            * config/rs6000/rs6000.cc (rs6000_mangle_type): Don't mangle
            float128_type_node as "u9__ieee128".
            * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Use
            float128t_type_node for __float128 instead of float128_type_node
            and create it if NULL.
    gcc/c-family/
            * c-common.cc (c_common_reswords): Change _Float{16,32,64,128} and
            _Float{32,64,128}x flags from D_CONLY to 0.
            (shorten_binary_op): Punt if common_type returns error_mark_node.
            (shorten_compare): Likewise.
            (c_common_nodes_and_builtins): For C++ record _Float{16,32,64,128}
            and _Float{32,64,128}x builtin types if available.  For C++
            clear float128t_type_node.
            * c-cppbuiltin.cc (c_cpp_builtins): Predefine
            __STDCPP_FLOAT{16,32,64,128}_T__ for C++23 if supported.
            * c-lex.cc (interpret_float): For q/Q suffixes prefer
            float128t_type_node over float128_type_node.  Allow
            {f,F}{16,32,64,128} suffixes for C++ if supported with pedwarn
            for C++20 and older.  Allow {f,F}{32,64,128}x suffixes for C++
            with pedwarn.  Don't call excess_precision_type for C++.
    gcc/cp/
            * cp-tree.h (cp_compare_floating_point_conversion_ranks): Implement
            P1467R9 - Extended floating-point types and standard names except
            for std::bfloat16_t for now.  Declare.
            (extended_float_type_p): New inline function.
            * mangle.cc (write_builtin_type): Mangle
float{16,32,64,128}_type_node
            as DF{16,32,64,128}_.  Mangle float{32,64,128}x_type_node as
            DF{32,64,128}x.  Remove FIXED_POINT_TYPE mangling that conflicts
            with that.
            * typeck2.cc (check_narrowing): If one of ftype or type is extended
            floating-point type, compare floating-point conversion ranks.
            * parser.cc (cp_keyword_starts_decl_specifier_p): Handle
            CASE_RID_FLOATN_NX.
            (cp_parser_simple_type_specifier): Likewise and diagnose missing
            _Float<N> or _Float<N>x support if not supported by target.
            * typeck.cc (cp_compare_floating_point_conversion_ranks): New
function.
            (cp_common_type): If both types are REAL_TYPE and one or both are
            extended floating-point types, select common type based on
comparison
            of floating-point conversion ranks and subranks.
            (cp_build_binary_op): Diagnose operation with floating point
arguments
            with unordered conversion ranks.
            * call.cc (standard_conversion): For floating-point conversion, if
            either from or to are extended floating-point types, set
conv->bad_p
            for implicit conversion from larger to smaller conversion rank or
            with unordered conversion ranks.
            (convert_like_internal): Emit a pedwarn on such conversions.
            (build_conditional_expr): Diagnose operation with floating point
            arguments with unordered conversion ranks.
            (convert_arg_to_ellipsis): Don't promote extended floating-point
types
            narrower than double to double.
            (compare_ics): Implement P1467R9 [over.ics.rank]/4 changes.
    gcc/testsuite/
            * g++.dg/cpp23/ext-floating1.C: New test.
            * g++.dg/cpp23/ext-floating2.C: New test.
            * g++.dg/cpp23/ext-floating3.C: New test.
            * g++.dg/cpp23/ext-floating4.C: New test.
            * g++.dg/cpp23/ext-floating5.C: New test.
            * g++.dg/cpp23/ext-floating6.C: New test.
            * g++.dg/cpp23/ext-floating7.C: New test.
            * g++.dg/cpp23/ext-floating8.C: New test.
            * g++.dg/cpp23/ext-floating9.C: New test.
            * g++.dg/cpp23/ext-floating10.C: New test.
            * g++.dg/cpp23/ext-floating.h: New file.
            * g++.target/i386/float16-1.C: Adjust expected diagnostics.
    libcpp/
            * expr.cc (interpret_float_suffix): Allow {f,F}{16,32,64,128} and
            {f,F}{32,64,128}x suffixes for C++.
    include/
            * demangle.h (enum demangle_component_type): Add
            DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
            (struct demangle_component): Add u.s_extended_builtin member.
    libiberty/
            * cp-demangle.c (d_dump): Handle
            DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Don't handle
            DEMANGLE_COMPONENT_FIXED_TYPE.
            (d_make_extended_builtin_type): New function.
            (cplus_demangle_builtin_types): Add _Float entry.
            (cplus_demangle_type): For DF demangle it as _Float<N> or
            _Float<N>x rather than fixed point which conflicts with it.
            (d_count_templates_scopes): Handle
            DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Just break; for
            DEMANGLE_COMPONENT_FIXED_TYPE.
            (d_find_pack): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
            Don't handle DEMANGLE_COMPONENT_FIXED_TYPE.
            (d_print_comp_inner): Likewise.
            * cp-demangle.h (D_BUILTIN_TYPE_COUNT): Bump.
            * testsuite/demangle-expected: Replace _Z3xxxDFyuVb test
            with _Z3xxxDF16_DF32_DF64_DF128_CDF16_Vb.  Add
            _Z3xxxDF32xDF64xDF128xCDF32xVb test.
    fixincludes/
            * inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
            glibc_cxx_floatn_3): New fixes.
            * tests/base/bits/floatn.h: New file.
            * fixincl.x: Regenerated.

[Bug c++/85518] ICE mangling _FloatN types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |13.0
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.