aboutsummaryrefslogtreecommitdiff
path: root/libiberty/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2023-06-13c++: Fix templated convertion operator demanglingNathan Sidwell1-0/+27
Instantiations of templated conversion operators failed to demangle for cases such as 'operator X<int>', but worked for 'operator X<int> &', due to thinking the template instantiation of X was the instantiation of the conversion operator itself. libiberty/ * cp-demangle.c (d_print_conversion): Remove incorrect template instantiation handling. * testsuite/demangle-expected: Add testcases.
2023-06-03c++: mangle noexcept-expr [PR70790]Patrick Palka1-0/+3
This implements noexcept(expr) mangling and demangling as per the Itanium ABI. PR c++/70790 gcc/cp/ChangeLog: * mangle.cc (write_expression): Handle NOEXCEPT_EXPR. libiberty/ChangeLog: * cp-demangle.c (cplus_demangle_operators): Add the noexcept operator. (d_print_comp_inner) <case DEMANGLE_COMPONENT_UNARY>: Always print parens around the operand of noexcept too. * testsuite/demangle-expected: Test noexcept operator demangling. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle78.C: New test.
2023-01-16Update copyright years.Jakub Jelinek6-6/+6
2022-11-15demangler: Templated lambda demanglingNathan Sidwell1-0/+53
Templated lambdas have a template-head, which is part of their signature. GCC ABI 18 mangles that into the lambda name. This adds support to the demangler. We have to introduce artificial template parameter names, as we need to refer to them from later components of the lambda signature. We use $T:n, $N:n and $TT:n for type, non-type and template parameters. Non-type parameter names are not shown in the strictly correct location -- for instance 'int (&NT) ()' would be shown as 'int (&) $N:n'. That's unfortunate, but an orthogonal issue. The 'is_lambda_arg' field is now repurposed as indicating the number of explicit template parameters (1-based). include/ * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_TEMPLATE_HEAD, DEMANGLE_COMPONENT_TEMPLATE_TYPE_PARM, DEMANGLE_COMPONENT_TEMPLATE_NON_TYPE_PARM, DEMANGLE_COMPONENT_TEMPLATE_TEMPLATE_PARM, DEMANGLE_COMPONENT_TEMPLATE_PACK_PARM. libiberty/ * cp-demangle.c (struct d_print_info): Rename is_lambda_arg to lambda_tpl_parms. Augment semantics. (d_make_comp): Add checks for new components. (d_template_parm, d_template_head): New. (d_lambda): Add templated lambda support. (d_print_init): Adjust. (d_print_lambda_parm_name): New. (d_print_comp_inner): Support templated lambdas, * testsuite/demangle-expected: Add testcases.
2022-10-14middle-end, c++, i386, libgcc: std::bfloat16_t and __bf16 arithmetic supportJakub Jelinek1-0/+4
Here is a complete patch to add std::bfloat16_t support on x86 (AArch64 and ARM left for later). Almost no BFmode optabs are added by the patch, so for binops/unops it extends to SFmode first and then truncates back to BFmode. For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has implementations of all those conversions so that we avoid double rounding, for BFmode -> {DF,XF,TF}mode conversions to avoid growing libgcc too much it emits BFmode -> SFmode conversion first and then converts to the even wider mode, neither step should be imprecise. For BFmode -> HFmode, it first emits a precise BFmode -> SFmode conversion and then SFmode -> HFmode, because neither format is subset or superset of the other, while SFmode is superset of both. expr.cc then contains a -ffast-math optimization of the BF -> SF and SF -> BF conversions if we don't optimize for space (and for the latter if -frounding-math isn't enabled either). For x86, perhaps truncsfbf2 optab could be defined for TARGET_AVX512BF16 but IMNSHO should FAIL if !flag_finite_math || flag_rounding_math || !flag_unsafe_math_optimizations, because I think the insn doesn't raise on sNaNs, hardcodes round to nearest and flushes denormals to zero. By default (unless x86 -fexcess-precision=16) we use float excess precision for BFmode, so truncate only on explicit casts and assignments. The patch introduces a single __bf16 builtin - __builtin_nansf16b, because (__bf16) __builtin_nansf ("") will drop the sNaN into qNaN, and uses f16b suffix instead of bf16 because there would be ambiguity on log vs. logb - __builtin_logbf16 could be either log with bf16 suffix or logb with f16 suffix. In other cases libstdc++ should mostly use __builtin_*f for std::bfloat16_t overloads (we have a problem with std::nextafter though but that one we have also for std::float16_t). 2022-10-14 Jakub Jelinek <jakub@redhat.com> gcc/ * tree-core.h (enum tree_index): Add TI_BFLOAT16_TYPE. * tree.h (bfloat16_type_node): Define. * tree.cc (excess_precision_type): Promote bfloat16_type_mode like float16_type_mode. (build_common_tree_nodes): Initialize bfloat16_type_node if BFmode is supported. * expmed.h (maybe_expand_shift): Declare. * expmed.cc (maybe_expand_shift): No longer static. * expr.cc (convert_mode_scalar): Don't ICE on BF -> HF or HF -> BF conversions. If there is no optab, handle BF -> {DF,XF,TF,HF} conversions as separate BF -> SF -> {DF,XF,TF,HF} conversions, add -ffast-math generic implementation for BF -> SF and SF -> BF conversions. * builtin-types.def (BT_BFLOAT16, BT_FN_BFLOAT16_CONST_STRING): New. * builtins.def (BUILT_IN_NANSF16B): New builtin. * fold-const-call.cc (fold_const_call): Handle CFN_BUILT_IN_NANSF16B. * config/i386/i386.cc (classify_argument): Handle E_BCmode. (ix86_libgcc_floating_mode_supported_p): Also return true for BFmode for -msse2. (ix86_mangle_type): Mangle BFmode as DF16b. (ix86_invalid_conversion, ix86_invalid_unary_op, ix86_invalid_binary_op): Remove. (TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP, TARGET_INVALID_BINARY_OP): Don't redefine. * config/i386/i386-builtins.cc (ix86_bf16_type_node): Remove. (ix86_register_bf16_builtin_type): Use bfloat16_type_node rather than ix86_bf16_type_node, only create it if still NULL. * config/i386/i386-builtin-types.def (BFLOAT16): Likewise. * config/i386/i386.md (cbranchbf4, cstorebf4): New expanders. gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): If bfloat16_type_node, predefine __BFLT16_*__ macros and for C++23 also __STDCPP_BFLOAT16_T__. Predefine bfloat16_type_node related macros for -fbuilding-libgcc. * c-lex.cc (interpret_float): Handle CPP_N_BFLOAT16. gcc/c/ * c-typeck.cc (convert_arguments): Don't promote __bf16 to double. gcc/cp/ * cp-tree.h (extended_float_type_p): Return true for bfloat16_type_node. * typeck.cc (cp_compare_floating_point_conversion_ranks): Set extended{1,2} if mv{1,2} is bfloat16_type_node. Adjust comment. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_bfloat16, check_effective_target_bfloat16_runtime, add_options_for_bfloat16): New. * gcc.dg/torture/bfloat16-basic.c: New test. * gcc.dg/torture/bfloat16-builtin.c: New test. * gcc.dg/torture/bfloat16-builtin-issignaling-1.c: New test. * gcc.dg/torture/bfloat16-complex.c: New test. * gcc.dg/torture/builtin-issignaling-1.c: Allow to be includable from bfloat16-builtin-issignaling-1.c. * gcc.dg/torture/floatn-basic.h: Allow to be includable from bfloat16-basic.c. * gcc.target/i386/vect-bfloat16-typecheck_2.c: Adjust expected diagnostics. * gcc.target/i386/sse2-bfloat16-scalar-typecheck.c: Likewise. * gcc.target/i386/vect-bfloat16-typecheck_1.c: Likewise. * g++.target/i386/bfloat_cpp_typecheck.C: Likewise. libcpp/ * include/cpplib.h (CPP_N_BFLOAT16): Define. * expr.cc (interpret_float_suffix): Handle bf16 and BF16 suffixes for C++. libgcc/ * config/i386/t-softfp (softfp_extensions): Add bfsf. (softfp_truncations): Add tfbf xfbf dfbf sfbf hfbf. (CFLAGS-extendbfsf2.c, CFLAGS-truncsfbf2.c, CFLAGS-truncdfbf2.c, CFLAGS-truncxfbf2.c, CFLAGS-trunctfbf2.c, CFLAGS-trunchfbf2.c): Add -msse2. * config/i386/libgcc-glibc.ver (GCC_13.0.0): Export __extendbfsf2 and __trunc{s,d,x,t,h}fbf2. * config/i386/sfp-machine.h (_FP_NANSIGN_B): Define. * config/i386/64/sfp-machine.h (_FP_NANFRAC_B): Define. * config/i386/32/sfp-machine.h (_FP_NANFRAC_B): Define. * soft-fp/brain.h: New file. * soft-fp/truncsfbf2.c: New file. * soft-fp/truncdfbf2.c: New file. * soft-fp/truncxfbf2.c: New file. * soft-fp/trunctfbf2.c: New file. * soft-fp/trunchfbf2.c: New file. * soft-fp/truncbfhf2.c: New file. * soft-fp/extendbfsf2.c: New file. libiberty/ * cp-demangle.h (D_BUILTIN_TYPE_COUNT): Increment. * cp-demangle.c (cplus_demangle_builtin_types): Add std::bfloat16_t entry. (cplus_demangle_type): Demangle DF16b. * testsuite/demangle-expected (_Z3xxxDF16b): New test.
2022-10-11libiberty: Demangling 'M' prefixesNathan Sidwell1-0/+21
The grammar for a lambda context can include <source-name> 'M', and we were adding the component that generated to the substitution table twice. Just ignore the 'M' completely -- we'll already have done the checks we need when we saw its predecessor. A prefix cannot be the last component of a nested name, so we do not need to check for that case (although we could if we wanted to be more lenient). libiberty/ * cp-demangle.c (d_prefix): 'M' components are not (re-)added to the substitution table. * testsuite/demangle-expected: Add tests.
2022-10-07libiberty: Demangle variadic template lambdasNathan Sidwell1-0/+7
Now we have templated lambdas, we can have variadic template lambdas, and this leads to lambda signatures containing parameter packs. But just like 'auto' inside such a signature, we don't have a containing template, and thus fail. The fix is to check is_lambda_arg, just as for a template parameter. This allows us to demangle g++'s manglings of such lambdas. It's not a totally accurate demangling, because we don't mangle the template head (that's a separate issue), but it is better than failing to demangle. Due to the way we print subexprs, we add an unnecessary parens around the argument of the pack. That's an orthogonal problem, for which the solution is to have better knowledge of operator precedence. libiberty/ * cp-demangle.c (d_print_comp_inner): Allow parameter packs in a lambda signature. * testsuite/demangle-expected: Add tests.
2022-09-27c++: Implement P1467R9 - Extended floating-point types and standard names ↵Jakub Jelinek1-2/+6
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.
2022-05-23demangler: C++ modules supportNathan Sidwell1-0/+67
This adds demangling support for C++ modules. A new 'W' component along with augmented behaviour of 'S' components. include/ * demangle.h (enum demangle_component_type): Add module components. libiberty/ * cp-demangle.c (d_make_comp): Adjust. (d_name, d_prefix): Adjust subst handling. Add module handling. (d_maybe_module_name): New. (d_unqualified_name): Add incoming module parm. Handle it. Adjust all callers. (d_special_name): Add 'GI' support. (d_count_template_scopes): Adjust. (d_print_comp_inner): Print module. * testsuite/demangle-expected: New test cases
2022-05-17demangler: Structured BindingsNathan Sidwell1-0/+10
C++ Structured bindings have a mangling that has yet to be formally documented. However, it's been around for a while and shows up for module support. include/ * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_STRUCTURED_BINDING. libiberty/ * cp-demangle.c (d_make_comp): Adjust. (d_unqualified_name): Add 'DC' support. (d_count_template_scopes): Adjust. (d_print_comp_inner): Add structured binding. * testsuite/demangle-expected: Add testcases.
2022-02-17libiberty rust-demangle, ignore .suffixMark Wielaard1-0/+26
Rust symbols can have a .suffix because of compiler transformations. These can be ignored in the demangled name. Which is what this patch implements. By stopping at the first dot for v0 symbols and searching backwards to the ending 'E' for legacy symbols. An alternative implementation could be to follow what C++ does and represent these as [clone .suffix] tagged onto the demangled name. But this seems somewhat confusing since it results in a demangled name that cannot be mangled again. And it would mean trying to decode compiler internal naming. https://bugs.kde.org/show_bug.cgi?id=445916 https://github.com/rust-lang/rust/issues/60705 libiberty/Changelog * rust-demangle.c (rust_demangle_callback): Ignore everything after '.' char in sym for v0. For legacy symbols search backwards to find the last 'E' before any '.'. * testsuite/rust-demangle-expected: Add new .suffix testcases.
2022-01-03Update copyright years.Jakub Jelinek6-6/+6
2021-12-30libiberty: support digits in cpp mangled clone namesLancelot SIX1-0/+5
Currently libiberty fails to demangle the name of cloned functions if the clone-type-identifier contains numbers. This can be observed with the following example: $ cat > ex.cc <<EOT void foo (float *, float *) __attribute__((target_clones("avx2,avx,sse4.1,default"))); void foo (float *, float *) {} EOT $ gcc -c ex.cc $ nm -C ex.o | grep foo 0000000000000000 i foo(float*, float*) 0000000000000026 t foo(float*, float*) [clone .avx.1] 0000000000000013 t _Z3fooPfS_.avx2.0 0000000000000000 t foo(float*, float*) [clone .default.3] 0000000000000000 W foo(float*, float*) [clone .resolver] 0000000000000039 t _Z3fooPfS_.sse4_1.2 In this example, gcc creates clones for the FOO function, each matching one of the specified targets. When inspecting the binary, nm (and other libiberty-based tools, including gdb) fails to demangle the symbol names if the clone identifier contains numbers. Form my understanding of the mangling convention[1], clone names are part of vendor-specific suffixes and do not have rule preventing them from containing digits. This commit proposes to fix the demangling. With this commit (ported to binutils), nm gives the following output: $ nm-new -C ex.o | grep foo 0000000000000000 i foo(float*, float*) 0000000000000026 t foo(float*, float*) [clone .avx.1] 0000000000000013 t foo(float*, float*) [clone .avx2.0] 0000000000000000 t foo(float*, float*) [clone .default.3] 0000000000000000 W foo(float*, float*) [clone .resolver] 0000000000000039 t foo(float*, float*) [clone .sse4_1.2] Tested on x86_86-linux with 'make check-libiberty'. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling libiberty/ChangeLog: * cp-demangle.c (d_clone_suffix): Support digits in clone tag names. * testsuite/demangle-expected: Check demangling of clone symbols with digits in name.
2021-10-17[PATCH] d-demangle: properly skip anonymous symbolsLuís Ferreira1-0/+8
libiberty/ PR d/102618 * d-demangle.c (dlang_parse_qualified): Handle anonymous symbols correctly. * testsuite/d-demangle-expected: New tests to cover anonymous symbols.
2021-10-14libiberty: d-demangle: Add test case for function literalsLuís Ferreira1-0/+4
libiberty/ChangeLog: * testsuite/d-demangle-expected: Add test case for function literals.
2021-10-14libiberty: d-demangle: add test cases for simple special manglesLuís Ferreira1-0/+8
libiberty/ChangeLog: * testsuite/d-demangle-expected: Add test cases for simple special mangles.
2021-10-01libiberty: testsuite: add missing format on d-demangle-expectedLuís Ferreira1-0/+1
libiberty * testsuite/d-demangle-expected: Add missing format for new test
2021-09-23libiberty: prevent null dereferencing on dlang_typeLuís Ferreira1-1/+4
libiberty/ * d-demangle.c (dlang_Type): Validate MANGLED is nonnull. * testsuite/d-demangle-expected: New test.
2021-08-30libiberty: Add support for demangling local D template declarationsIain Buclaw1-0/+24
The D language now allows multiple different template declarations in the same function that have the same mangled name. To make the mangled names unique, a fake parent in the form `__Sddd' is added to the symbol. This information is not important for the user, so the demangler now handles and ignores it. libiberty/ChangeLog: * d-demangle.c (dlang_identifier): Skip over fake parent manglings. * testsuite/d-demangle-expected: Add tests.
2021-08-30libiberty: Add support for demangling D function literals as template value ↵Iain Buclaw1-0/+4
parameters The D language now allows instantiating templates using struct literals that have function literal fields as a value argument. libiberty/ChangeLog: * d-demangle.c (dlang_parse_arrayliteral): Add 'info' parameter. (dlang_parse_assocarray): Likewise. (dlang_parse_structlit): Likewise. (dlang_value): Likewise. Handle function literal symbols. (dlang_template_args): Pass 'info' to dlang_value. * testsuite/d-demangle-expected: Add new test.
2021-08-30libiberty: Add support for D `typeof(*null)' typesIain Buclaw1-1/+5
The D language has a new bottom type `typeof(*null)'. Null types were also incorrectly being demangled as `none', this has been fixed to be `typeof(null)'. libiberty/ChangeLog: * d-demangle.c (dlang_attributes): Handle typeof(*null). (dlang_type): Likewise. Demangle 'n' as typeof(null). * testsuite/d-demangle-expected: Update tests.
2021-03-30c++: Adjust mangling of __alignof__ [PR88115]Patrick Palka1-2/+2
r11-4926 made __alignof__ get mangled differently from alignof, encoding __alignof__ as a vendor extended operator. But this mangling is problematic for the reasons mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6. This patch changes our mangling of __alignof__ to instead use the new "vendor extended expression" syntax that's proposed in https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does the same thing already, so after this patch Clang and GCC agree about the mangling of __alignof__(type) and __alignof__(expr). gcc/cp/ChangeLog: PR c++/88115 * mangle.c (write_expression): Adjust the mangling of __alignof__. include/ChangeLog: PR c++/88115 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_VENDOR_EXPR. libiberty/ChangeLog: PR c++/88115 * cp-demangle.c (d_dump, d_make_comp, d_expression_1) (d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR. (d_print_comp_inner): Likewise. <case DEMANGLE_COMPONENT_EXTENDED_OPERATOR>: Revert r11-4926 change. <case DEMANGLE_COMPONENT_UNARY>: Likewise. * testsuite/demangle-expected: Adjust __alignof__ tests. gcc/testsuite/ChangeLog: PR c++/88115 * g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
2021-01-04Update copyright years.Jakub Jelinek6-6/+6
2020-12-21c++: Fix demangling of <unresolved-name>Jason Merrill1-0/+3
The ABI for unresolved scoped names on the RHS of . and -> used to be sr <type> <unqualified-id> That changed years ago to something more complex, but G++ was never updated. This change was particularly incompatible for simple qualified-ids like A::x, which were previously mangled as sr1A1x, and now sr1AE1x. This obviously makes life hard for demanglers, which can't know whether to consume that E or not. To work around this, we now try demangling with the newer ABI, and if that fails and we saw an "sr", try again with the older ABI. libiberty/ChangeLog: PR c++/67343 * cp-demangle.h (struct d_info): Add unresolved_name_state. * cp-demangle.c (d_prefix): Add subst parm. (d_nested_name): Pass it. (d_unresolved_name): Split out from... (d_expression_1): ...here. (d_demangle_callback): Maybe retry with old sr mangling. * testsuite/demangle-expected: Add test.
2020-12-21c++: Fix demangling of qualified-id after '.'Jason Merrill1-0/+3
The demangler was assuming that only an unqualified-id could appear after . or ->. libiberty/ChangeLog: * cp-demangle.c (d_expression_1): Recognize qualified-id on RHS of dt/pt. * testsuite/demangle-expected: Add test.
2020-12-21c++: Fix demangling of x.operator typeJason Merrill1-0/+6
d_operator_name decides whether "cv" indicates a cast or a conversion operator based on is_expression. "on" specifies that we want the conversion operator. libiberty/ChangeLog: * cp-demangle.c (d_unqualified_name): Clear is_expression. * testsuite/demangle-expected: Add tests.
2020-11-13libiberty: Support the new ("v0") mangling scheme in rust-demangleEduard-Mihai Burtescu1-1/+133
This is the libiberty (mainly for binutils/gdb) counterpart of https://github.com/alexcrichton/rustc-demangle/pull/23. Relevant links for the new Rust mangling scheme (aka "v0"): * Rust RFC: https://github.com/rust-lang/rfcs/pull/2603 * tracking issue: https://github.com/rust-lang/rust/issues/60705 * implementation: https://github.com/rust-lang/rust/pull/57967 This implementation includes full support for UTF-8 identifiers via punycode, so I've included a testcase for that as well. libiberty/ChangeLog: * rust-demangle.c (struct rust_demangler): Add skipping_printing and bound_lifetime_depth fields. (eat): Add (v0-only). (parse_integer_62): Add (v0-only). (parse_opt_integer_62): Add (v0-only). (parse_disambiguator): Add (v0-only). (struct rust_mangled_ident): Add punycode{,_len} fields. (parse_ident): Support v0 identifiers. (print_str): Respect skipping_printing. (print_uint64): Add (v0-only). (print_uint64_hex): Add (v0-only). (print_ident): Respect skipping_printing, Support v0 identifiers. (print_lifetime_from_index): Add (v0-only). (demangle_binder): Add (v0-only). (demangle_path): Add (v0-only). (demangle_generic_arg): Add (v0-only). (demangle_type): Add (v0-only). (demangle_path_maybe_open_generics): Add (v0-only). (demangle_dyn_trait): Add (v0-only). (demangle_const): Add (v0-only). (demangle_const_uint): Add (v0-only). (basic_type): Add (v0-only). (rust_demangle_callback): Support v0 symbols. * testsuite/rust-demangle-expected: Add v0 testcases.
2020-11-11c++: Change the mangling of __alignof__ [PR88115]Patrick Palka1-0/+7
This patch changes the mangling of __alignof__ to v111__alignof__, making its mangling distinct from that of alignof(type) and alignof(expr). How we mangle ALIGNOF_EXPR now depends on its ALIGNOF_EXPR_STD_P flag, which after the previous patch gets consistently set for alignof(type) as well as alignof(expr). gcc/c-family/ChangeLog: PR c++/88115 * c-opts.c (c_common_post_options): Update latest_abi_version. gcc/ChangeLog: PR c++/88115 * common.opt (-fabi-version): Document =15. * doc/invoke.texi (C++ Dialect Options): Likewise. gcc/cp/ChangeLog: PR c++/88115 * mangle.c (write_expression): Mangle __alignof_ differently from alignof when the ABI version is at least 15. libiberty/ChangeLog: PR c++/88115 * cp-demangle.c (d_print_comp_inner) <case DEMANGLE_COMPONENT_EXTENDED_OPERATOR>: Don't print the "operator " prefix for __alignof__. <case DEMANGLE_COMPONENT_UNARY>: Always print parens around the operand of __alignof__. * testsuite/demangle-expected: Test demangling for __alignof__. gcc/testsuite/ChangeLog: PR c++/88115 * g++.dg/abi/macro0.C: Adjust. * g++.dg/cpp0x/alignof7.C: New test. * g++.dg/cpp0x/alignof8.C: New test.
2020-09-08ubsan: d-demangle.c:214 signed integer overflowAlan Modra1-0/+8
Running the libiberty testsuite ./test-demangle < libiberty/testsuite/d-demangle-expected libiberty/d-demangle.c:214:14: runtime error: signed integer overflow: 922337203 * 10 cannot be represented in type 'long int' On looking at silencing ubsan, I found a real bug in dlang_number. For a 32-bit long, some overflows won't be detected. For example, 21474836480. Why? Well 214748364 * 10 is 0x7FFFFFF8 (no overflow so far). Adding 8 gives 0x80000000 (which does overflow but there is no test for that overflow in the code). Then multiplying 0x80000000 * 10 = 0x500000000 = 0 won't be caught by the multiplication overflow test. The same holds for a 64-bit long using similarly crafted digit sequences. * d-demangle.c: Include limits.h. (ULONG_MAX, UINT_MAX): Provide fall-back definition. (dlang_number): Simplify and correct overflow test. Only write *ret on returning non-NULL. Make "ret" an unsigned long*. Only succeed for result of [0,UINT_MAX]. (dlang_decode_backref): Simplify and correct overflow test. Only write *ret on returning non-NULL. Only succeed for result [1,MAX_LONG]. (dlang_backref): Remove now unnecessary range check. (dlang_symbol_name_p): Likewise. (string_need): Take a size_t n arg, and use size_t tem. (string_append): Use size_t n. (string_appendn, string_prependn): Take a size_t n arg. (TEMPLATE_LENGTH_UNKNOWN): Define as -1UL. (dlang_lname, dlang_parse_template): Take an unsigned long len arg. (dlang_symbol_backref, dlang_identifier, dlang_parse_integer), (dlang_parse_integer, dlang_parse_string), (dlang_parse_arrayliteral, dlang_parse_assocarray), (dlang_parse_structlit, dlang_parse_tuple), (dlang_template_symbol_param, dlang_template_args): Use unsigned long variables. * testsuite/d-demangle-expected: Add new tests.
2020-08-26libiberty: Add support for `in' and `in ref' storage classes.Iain Buclaw1-8/+8
The storage class `in' is now a first-class citizen with its own mangle symbol, of which also permits `in ref'. Previously, `in' was an alias to `const [scope]', which is a type constructor. The mangle symbol repurposed for this is `I', which was originally used by identifier types. However, while TypeIdentifier is part of the grammar, it must be resolved to some other entity during the semantic passes, and so shouldn't appear anywhere in the mangled name. Old tests that are now no longer valid have been removed. libiberty/ChangeLog: * d-demangle.c (dlang_function_args): Handle 'in' and 'in ref' parameter storage classes. (dlang_type): Remove identifier type. * testsuite/d-demangle-expected: Update tests.
2020-07-14demangler: don't treat lambda as a substitution candidateIan Lance Taylor1-5/+9
libiberty/ChangeLog: PR demangler/96143 * cp-demangle.c (d_lambda): Don't add substitution candidate. * testsuite/demangle-expected: Update a few existing test cases accordingly, and add a new test case.
2020-07-10c++: Support non-type template parms of union type.Jason Merrill1-0/+9
Another thing newly allowed by P1907R1. The ABI group has discussed representing unions with designated initializers, and has separately specified how to represent designators; this patch implements both. gcc/cp/ChangeLog: * tree.c (structural_type_p): Allow unions. * mangle.c (write_expression): Express unions with a designator. libiberty/ChangeLog: * cp-demangle.c (cplus_demangle_operators): Add di, dx, dX. (d_expression_1): Handle di and dX. (is_designated_init, d_maybe_print_designated_init): New. (d_print_comp_inner): Use d_maybe_print_designated_init. * testsuite/demangle-expected: Add designator tests. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-class-union1.C: New test.
2020-05-15libiberty: Handle @live attribute in D demangler.Iain Buclaw1-0/+8
Adds support for demangling D functions annotated with the new ownership/borrowing system attribute. libiberty/ChangeLog: * d-demangle.c (dlang_attributes): Add @live attribute. * testsuite/d-demangle-expected: Add new tests.
2020-05-14libiberty: Update D symbol demangling for latest ABI spec.Iain Buclaw1-0/+72
Some small improvements and clarifications have been done in the D ABI specification to remove all ambiguities found in the current grammar, this implementation now more closely resembles the spec, whilst maintaining compatibility with the old ABI. Three new rules have been added to the ABI. 1. Back references using 'Q', analogous to C++ substitutions, compresses repeated identifiers, types, and template symbol and value parameters. 2. Template aliases to externally mangled symbols are prefixed with 'X'. This includes any symbol that isn't extern(D), or has its name overriden with pragma(mangle). This fixes an ambiguity where it was not clear whether 'V' was an encoded calling convention, or the next template value parameter. 3. Alias parameters, templates, and tuple symbols no longer encode the symbol length of its subpart. Tuples are now terminated with 'Z'. This fixes another ambiguity where the first character of the mangled name can be a digit as well, so the demangler had to figure out where to split the two adjacent numbers by trying out each combination. libiberty/ChangeLog: * d-demangle.c (enum dlang_symbol_kinds): Remove enum. (struct dlang_info): New struct (dlang_decode_backref): New function. (dlang_backref): New function. (dlang_symbol_backref): New function. (dlang_type_backref): New function. (dlang_symbol_name_p): New function. (dlang_function_type_noreturn): New function. (dlang_function_type): Add 'info' parameter. Decode function type with dlang_function_type_noreturn. (dlang_function_args): Add 'info' parameter. (dlang_type): Add 'info' parameter. Handle back referenced types. (dlang_identifier): Replace 'kind' parameter with 'info'. Handle back referenced symbols. Split off decoding of plain identifiers to... (dlang_lname): ...here. (dlang_parse_mangle): Replace 'kind' parameter with 'info'. Decode function type and return with dlang_type. (dlang_parse_qualified): Replace 'kind' parameter with 'info', add 'suffix_modifier' parameter. Decode function type with dlang_function_type_noreturn. (dlang_parse_tuple): Add 'info' parameter. (dlang_template_symbol_param): New function. (dlang_template_args): Add 'info' parameter. Decode symbol parameter with dlang_template_symbol_param. Handle back referenced values, and externally mangled parameters. (dlang_parse_template): Add 'info' parameter. (dlang_demangle_init_info): New function. (dlang_demangle): Initialize and pass 'info' parameter. * testsuite/d-demangle-expected: Add new tests. Co-Authored-By: Rainer Schuetze <r.sagitario@gmx.de>
2020-04-27demangler: Handle <=> operator in the demangler [PR94797]Jakub Jelinek1-0/+3
The demangler didn't handle spaceship operator. 2020-04-27 Jakub Jelinek <jakub@redhat.com> PR demangler/94797 * cp-demangle.c (cplus_demangle_operators): Add ss <=> operator. * testsuite/demangle-expected: Add operator<=> test.
2020-03-02Fix a libiberty testsuite failureNick Clifton1-1/+1
* testsuite/demangle-expected: Update expected demangling of enable_if pattern.
2020-01-18[libiberty] Update demangler to handle co_await operator.Iain Sandoe1-0/+3
C++20 coroutines introduces a new operator with a mangling of 'aw'. This patch adds that to libiberty's demangler. libiberty/ChangeLog: 2020-01-18 Iain Sandoe <iain@sandoe.co.uk> * cp-demangle.c (cplus_demangle_operators): Add the co_await operator. * testsuite/demangle-expected: Test co_await operator mangling.
2020-01-01Update copyright years.Jakub Jelinek6-6/+6
From-SVN: r279813
2019-11-16* testsuite/demangle-expected: Fix test.Miguel Saldivar1-1/+1
From-SVN: r278357
2019-11-04PR c++/91979 - mangling nullptr expressionKamlesh Kumar1-0/+4
2019-11-04 Kamlesh Kumar <kamleshbhalui@gmail.com> gcc/cp * cp/mangle.c (write_template_arg_literal): Handle nullptr mangling. gcc * common.opt (-fabi-version): Document =14. * doc/invoke.texi (C++ Dialect Options): Likewise. gcc/c-family * c-opts.c (c_common_post_options): Update latest_abi_version. libiberty * cp-demangle.c (d_expr_primary): Handle nullptr demangling. * testsuite/demangle-expected: Added test. From-SVN: r277801
2019-10-28cp-demangle.c (d_print_mod): Add a space before printing `complex` and ↵Miguel Saldivar1-1/+1
`imaginary`, as opposed to after. * cp-demangle.c (d_print_mod): Add a space before printing `complex` and `imaginary`, as opposed to after. * testsuite/demangle-expected: Adjust test. From-SVN: r277535
2019-10-03rust-demangle.c (looks_like_rust): Remove.Eduard-Mihai Burtescu1-1/+1
* rust-demangle.c (looks_like_rust): Remove. (rust_is_mangled): Don't check escapes. (is_prefixed_hash): Allow 0-9a-f permutations. (rust_demangle_sym): Don't bail on unknown escapes. * testsuite/rust-demangle-expected: Update 'main::$99$' test. From-SVN: r276539
2019-09-03rust-demangle.c (unescape): Remove.Eduard-Mihai Burtescu1-0/+4
* rust-demangle.c (unescape): Remove. (parse_lower_hex_nibble): New function. (parse_legacy_escape): New function. (is_prefixed_hash): Use parse_lower_hex_nibble. (looks_like_rust): Use parse_legacy_escape. (rust_demangle_sym): Use parse_legacy_escape. * testsuite/rust-demangle-expected: Add 'llv$u6d$' test. From-SVN: r275353
2019-04-30d-demangle.c (dlang_parse_assocarray): Correctly handle error result.Ben L1-0/+4
* d-demangle.c (dlang_parse_assocarray): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. From-SVN: r270700
2019-04-30d-demangle.c (dlang_parse_tuple): Correctly handle error result.Ben L1-0/+4
* d-demangle.c (dlang_parse_tuple): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. From-SVN: r270699
2019-04-30d-demangle.c (dlang_parse_structlit): Correctly handle error result.Ben L1-0/+4
* d-demangle.c (dlang_parse_structlit): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. From-SVN: r270698
2019-04-30d-demangle.c (dlang_parse_arrayliteral): Correctly handle error result.Ben L1-0/+4
* d-demangle.c (dlang_parse_arrayliteral): Correctly handle error result. * testsuite/d-demangle-expected: Add testcase. From-SVN: r270697
2019-04-30d-demangle.c (dlang_parse_integer): Fix stack underflow.Ben L1-0/+4
* d-demangle.c (dlang_parse_integer): Fix stack underflow. * testsuite/d-demangle-expected: Add testcase. From-SVN: r270696
2019-04-30cp-demangle (d_print_comp_inner): Guard against a NULL 'typed_name'.Ben L1-0/+4
* cp-demangle (d_print_comp_inner): Guard against a NULL 'typed_name'. * testsuite/demangle-expected: Add testcase. From-SVN: r270695
2019-04-30cp-demangle.c (d_encoding): Guard against NULL return values from d_right (dc).Ben L1-0/+5
* cp-demangle.c (d_encoding): Guard against NULL return values from d_right (dc). * testsuite/demangle-expected: Add testcase. From-SVN: r270694