aboutsummaryrefslogtreecommitdiff
path: root/libiberty
AgeCommit message (Collapse)AuthorFilesLines
2022-10-08Daily bump.GCC Administrator1-0/+6
2022-10-07libiberty: Demangle variadic template lambdasNathan Sidwell2-13/+24
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-28Daily bump.GCC Administrator1-0/+22
2022-09-27c++: Implement P1467R9 - Extended floating-point types and standard names ↵Jakub Jelinek3-42/+68
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-09-23Daily bump.GCC Administrator1-0/+4
2022-09-22libiberty: Refer to Bugzilla in READMEJonathan Wakely1-1/+1
We want bugs reported to Bugzilla, not emailed to gcc-bugs. libiberty/ChangeLog: * README: Replace gcc-bugs email address with Bugzilla URL.
2022-08-26Daily bump.GCC Administrator1-0/+4
2022-08-25regenerate configure files and config.h.in filesMartin Liska1-0/+3
fixincludes/ChangeLog: * config.h.in: Regenerate. * configure: Regenerate. libada/ChangeLog: * configure: Regenerate. libiberty/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. liboffloadmic/ChangeLog: * configure: Regenerate. * plugin/configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate.
2022-07-23Daily bump.GCC Administrator1-0/+6
2022-07-22remove 'continue' as last statement in loopMartin Liska1-1/+0
PR other/106370 gcc/cp/ChangeLog: * init.cc (sort_mem_initializers): Remove continue as last stmt in a loop. libiberty/ChangeLog: * _doprnt.c: Remove continue as last stmt in a loop.
2022-07-15Daily bump.GCC Administrator1-0/+4
2022-07-14libiberty: fix docs typoMartin Liska1-1/+1
libiberty/ChangeLog: * functions.texi: Replace strtoul with strtoull.
2022-07-05Daily bump.GCC Administrator1-0/+10
2022-07-04Fix typo in recent code to add stack recursion limit to the Rust demangler.Nick Clifton1-0/+1
libiberty * rust-demangle.c (demangle_const): Add a missing goto pass_return at the end of the function.
2022-07-04Prevent another potential stack overflow issue when demangling a maliciouslt ↵Nick Clifton1-0/+17
mangled Rust name. libiberty/ * rust-demangle.c (demangle_path_maybe_open_generics): Add recursion limit.
2022-07-02Daily bump.GCC Administrator1-0/+5
2022-07-01Add a recursion limit to the demangle_const function in the Rust demangler.Nick Clifton1-9/+20
libiberty/ PR demangler/105039 * rust-demangle.c (demangle_const): Add recursion limit.
2022-06-27Daily bump.GCC Administrator1-0/+5
2022-06-26Make it easier to rebuild configure files.Simon Marchi2-0/+2
Add AC_CONFIG_MACRO_DIRS([../config]) So that just running: $ autoreconf -vf ... does the right thing (no need to specify -I ../config). Note: I don't have access to the gcc repo, so if this patch is approved, can somebody push it there on my behalf? I can push it to binutils-gdb. libiberty/ChangeLog: * configure.ac: Add AC_CONFIG_MACRO_DIRS call. * configure: Re-generate.
2022-05-24Daily bump.GCC Administrator1-0/+11
2022-05-23demangler: C++ modules supportNathan Sidwell2-27/+182
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-19Daily bump.GCC Administrator1-0/+11
2022-05-18demangler: Reorganize for module demanglingNathan Sidwell1-139/+83
Module demangling requires some changes in how substitutions are handled. This adjusts things to make that possible. libiberty/ * cp-demangle.c (d_name): Add SUBSTABLE parameter, push substitution if requested. Adjust unscoped name handling. (d_prefix): Reorder main loop. Adjust all calls. (d_unqualified_name): Add SCOPE parameter, create qualified name here. Adjust all calls. (cplus_demangle_type): Do not handle 'S' here, leave all to d_class_enum_type. (d_class_enum_type): Add SUBSTABLE parameter.
2022-05-18Daily bump.GCC Administrator1-0/+8
2022-05-17demangler: Structured BindingsNathan Sidwell2-6/+53
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-05-11Daily bump.GCC Administrator1-0/+76
2022-05-10libiberty: fix wrong replacent in commentsMartin Liska1-4/+4
libiberty/ChangeLog: * regex.c: Restore comments.
2022-05-10libiberty: fix type in allocationMartin Liska1-4/+4
The allocation function alloc_f is called for nsize items where each is of type void *. libiberty/ChangeLog: * hashtab.c (htab_empty): Use void * type instead of void **. (htab_expand): Likewise. Co-Authored-By: Alan Modra <amodra@gmail.com>
2022-05-10libiberty: fix bad replacement.Martin Liska1-2/+0
libiberty/ChangeLog: * random.c: Remove 'define PTR'.
2022-05-10libiberty: stop using PTR macroMartin Liska23-115/+115
include/ChangeLog: * hashtab.h (HTAB_EMPTY_ENTRY): Use void * instead PTR. (HTAB_DELETED_ENTRY): Likewise. libiberty/ChangeLog: * alloca.c (C_alloca): Use void * instead PTR. * calloc.c (malloc): Likewise. (bzero): Likewise. (calloc): Likewise. * hashtab.c (find_empty_slot_for_expand): Likewise. (eq_pointer): Likewise. (htab_create_alloc_ex): Likewise. (htab_create_typed_alloc): Likewise. (htab_set_functions_ex): Likewise. (htab_delete): Likewise. (htab_empty): Likewise. (htab_expand): Likewise. (htab_find_with_hash): Likewise. (htab_find): Likewise. (htab_find_slot_with_hash): Likewise. (htab_find_slot): Likewise. (htab_remove_elt): Likewise. (htab_remove_elt_with_hash): Likewise. (htab_clear_slot): Likewise. (htab_traverse_noresize): Likewise. (htab_traverse): Likewise. (htab_hash_string): Likewise. (iterative_hash): Likewise. (hash_pointer): Likewise. * memchr.c (memchr): Likewise. * memcmp.c (memcmp): Likewise. * memcpy.c (memcpy): Likewise. * memmove.c (memmove): Likewise. * mempcpy.c (memcpy): Likewise. (mempcpy): Likewise. * memset.c (memset): Likewise. * objalloc.c (malloc): Likewise. (free): Likewise. (objalloc_create): Likewise. (_objalloc_alloc): Likewise. (objalloc_free_block): Likewise. * random.c (PTR): Likewise. (void): Likewise. (initstate): Likewise. (setstate): Likewise. * regex.c: Likewise. * spaces.c (malloc): Likewise. (free): Likewise. * stpcpy.c (memcpy): Likewise. * strdup.c (malloc): Likewise. (memcpy): Likewise. * strerror.c (malloc): Likewise. (memset): Likewise. * strndup.c (malloc): Likewise. (memcpy): Likewise. * strsignal.c (malloc): Likewise. (memset): Likewise. * vasprintf.c (malloc): Likewise. * vprintf-support.c: Likewise. * xatexit.c (malloc): Likewise. * xmalloc.c (xmalloc): Likewise. (xcalloc): Likewise. (xrealloc): Likewise. * xmemdup.c (xmemdup): Likewise.
2022-03-20Daily bump.GCC Administrator1-0/+6
2022-03-19rename floatformat_ia64_quad_{big, little} to floatformat_ieee_quad_{big, ↵Tiezhu Yang1-17/+17
little} I submitted a GDB patch [1] to rename floatformats_ia64_quad to floatformats_ieee_quad to reflect the reality, and then we can clean up the related code. As GDB Global Maintainer Tom Tromey said [2]: These files are maintained in gcc and then imported into the binutils-gdb repository, so any changes to them will have to be proposed there first. this GCC patch is preparation for the GDB patch, no functionality change. [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186452.html [2] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> include/ * floatformat.h (floatformat_ieee_quad_big): Renamed from floatformat_ia64_quad_big. (floatformat_ieee_quad_little): Similarly. libiberty/ * floatformat.c (floatformat_ieee_quad_big): Renamed from floatformat_ia64_quad_big. (floatformat_ieee_quad_little): Similarly.
2022-02-23Daily bump.GCC Administrator1-0/+9
2022-02-22libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]Jakub Jelinek1-7/+3
On #define A(n) int foo1##n(void) { return 1##n; } #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9) #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9) #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9) #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9) E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325) B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642) testcase with ./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto -O0 -o foo1.o foo1.c -ffunction-sections ./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o /tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized (testcase too slow to be included into testsuite). The problem is clearly reported by readelf: readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range sh_link value of 65321 readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range sh_link value of 65321 readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range sh_link value of 65323 readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should index a symtab section. readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should index a symtab section. readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should index a string section. because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info and sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE inclusive. Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be used instead and .symtab_shndx section should contain the real section index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >= SHN_LORESERVE value is needed it should put those into Shdr[0].sh_{size,link}. But, sh_{link,info} are 32-bit fields which can contain any section index. Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so before 2011) used to mishandle the > 63.75K sections case and assumed there is a hole in between the sections, but what simple_object_elf_copy_lto_debug_sections does wouldn't help in that case for the debug temp object creation, we'd need to detect the case also in that routine and take it into account in the remapping etc. I think it is not worth it given that it is over 10 years, if somebody needs 63.75K or more sections, better use more recent binutils. 2022-02-22 Jakub Jelinek <jakub@redhat.com> PR lto/104617 * simple-object-elf.c (simple_object_elf_match): Fix up URL in comment. (simple_object_elf_copy_lto_debug_sections): Remap sh_info and sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE range (inclusive).
2022-02-18Daily bump.GCC Administrator1-0/+7
2022-02-17libiberty rust-demangle, ignore .suffixMark Wielaard2-3/+44
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-02-01Daily bump.GCC Administrator1-0/+12
2022-01-31libiberty: Fix infinite recursion in rust demangler.Nick Clifton1-6/+41
libiberty/ PR demangler/98886 PR demangler/99935 * rust-demangle.c (struct rust_demangler): Add a recursion counter. (demangle_path): Increment/decrement the recursion counter upon entry and exit. Fail if the counter exceeds a fixed limit. (demangle_type): Likewise. (rust_demangle_callback): Initialise the recursion counter, disabling if requested by the option flags.
2022-01-16Daily bump.GCC Administrator1-0/+4
2022-01-15Add -Wuse-after-free [PR80532].Martin Sebor1-0/+4
gcc/c-family/ChangeLog PR tree-optimization/80532 * c.opt (-Wuse-after-free): New options. gcc/ChangeLog: PR tree-optimization/80532 * common.opt (-Wuse-after-free): New options. * diagnostic-spec.c (nowarn_spec_t::nowarn_spec_t): Handle OPT_Wreturn_local_addr and OPT_Wuse_after_free_. * diagnostic-spec.h (NW_DANGLING): New enumerator. * doc/invoke.texi (-Wuse-after-free): Document new option. * gimple-ssa-warn-access.cc (pass_waccess::check_call): Rename... (pass_waccess::check_call_access): ...to this. (pass_waccess::check): Rename... (pass_waccess::check_block): ...to this. (pass_waccess::check_pointer_uses): New function. (pass_waccess::gimple_call_return_arg): New function. (pass_waccess::warn_invalid_pointer): New function. (pass_waccess::check_builtin): Handle free and realloc. (gimple_use_after_inval_p): New function. (get_realloc_lhs): New function. (maybe_warn_mismatched_realloc): New function. (pointers_related_p): New function. (pass_waccess::check_call): Call check_pointer_uses. (pass_waccess::execute): Compute and free dominance info. libcpp/ChangeLog: * files.c (_cpp_find_file): Substitute a valid pointer for an invalid one to avoid -Wuse-after-free. libiberty/ChangeLog: * regex.c: Suppress -Wuse-after-free. gcc/testsuite/ChangeLog: PR tree-optimization/80532 * gcc.dg/Wmismatched-dealloc-2.c: Avoid -Wuse-after-free. * gcc.dg/Wmismatched-dealloc-3.c: Same. * gcc.dg/analyzer/file-1.c: Prune expected warning. * gcc.dg/analyzer/file-2.c: Same. * gcc.dg/attr-alloc_size-6.c: Disable -Wuse-after-free. * gcc.dg/attr-alloc_size-7.c: Same. * c-c++-common/Wuse-after-free-2.c: New test. * c-c++-common/Wuse-after-free-3.c: New test. * c-c++-common/Wuse-after-free-4.c: New test. * c-c++-common/Wuse-after-free-5.c: New test. * c-c++-common/Wuse-after-free-6.c: New test. * c-c++-common/Wuse-after-free-7.c: New test. * c-c++-common/Wuse-after-free.c: New test. * g++.dg/warn/Wmismatched-dealloc-3.C: New test. * g++.dg/warn/Wuse-after-free.C: New test.
2022-01-03Update copyright years.Jakub Jelinek94-95/+95
2021-12-31Daily bump.GCC Administrator1-0/+7
2021-12-30libiberty: support digits in cpp mangled clone namesLancelot SIX2-2/+8
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-12-17Daily bump.GCC Administrator1-0/+13
2021-12-15Revert "Sync with binutils: GCC: Pass --plugin to AR and RANLIB"H.J. Lu4-53/+2
This reverts commit bf8cdd35117dea2049abbeebcdf14de11b323ef7.
2021-12-16Daily bump.GCC Administrator1-0/+10
2021-12-15Sync with binutils: GCC: Pass --plugin to AR and RANLIBH.J. Lu4-2/+53
Sync with binutils for building binutils with LTO: 50ad1254d50 GCC: Pass --plugin to AR and RANLIB Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. ChangeLog: * Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. * configure.ac: Include config/gcc-plugin.m4. AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and RANLIB if possible. * Makefile.in: Regenerated. * configure: Likewise. config/ * gcc-plugin.m4 (GCC_PLUGIN_OPTION): New. libiberty/ * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. (configure_deps): Depend on ../config/gcc-plugin.m4. * configure.ac: AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * aclocal.m4: Regenerated. * configure: Likewise. zlib/ * configure: Regenerated.
2021-11-30Daily bump.GCC Administrator1-0/+12
2021-11-29Make etags path used by build system configurableEric Gallager3-1/+14
This commit allows users to specify a path to their "etags" executable for use when doing "make tags". I based this patch off of this one from upstream automake: https://git.savannah.gnu.org/cgit/automake.git/commit/m4?id=d2ccbd7eb38d6a4277d6f42b994eb5a29b1edf29 This means that I just supplied variables that the user can override for the tags programs, rather than having the configure scripts actually check for them. I handle etags and ctags separately because the intl subdirectory has separate targets for them. This commit only affects the subdirectories that use handwritten Makefiles; the ones that use automake will have to wait until we update the version of automake used to be 1.16.4 or newer before they'll be fixed. Addresses #103021 gcc/ChangeLog: PR other/103021 * Makefile.in: Substitute CTAGS, ETAGS, and CSCOPE variables. Use ETAGS variable in TAGS target. * configure: Regenerate. * configure.ac: Allow CTAGS, ETAGS, and CSCOPE variables to be overridden. gcc/ada/ChangeLog: PR other/103021 * gcc-interface/Make-lang.in: Use ETAGS variable in TAGS target. gcc/c/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. gcc/cp/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. gcc/d/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. gcc/fortran/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. gcc/go/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. gcc/objc/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. gcc/objcp/ChangeLog: PR other/103021 * Make-lang.in: Use ETAGS variable in TAGS target. intl/ChangeLog: PR other/103021 * Makefile.in: Use ETAGS variable in TAGS target, CTAGS variable in CTAGS target, and MKID variable in ID target. * configure: Regenerate. * configure.ac: Allow CTAGS, ETAGS, and MKID variables to be overridden. libcpp/ChangeLog: PR other/103021 * Makefile.in: Use ETAGS variable in TAGS target. * configure: Regenerate. * configure.ac: Allow ETAGS variable to be overridden. libiberty/ChangeLog: PR other/103021 * Makefile.in: Use ETAGS variable in TAGS target. * configure: Regenerate. * configure.ac: Allow ETAGS variable to be overridden.
2021-11-29Fix PR 19089: Environment variable TMP may yield gcc: abortAndrew Pinski1-1/+15
Even though I cannot reproduce the ICE any more, this is still a bug. We check already to see if we can access the directory but never check to see if the path is actually a directory. This adds the check and now we reject the file as not usable as a tmp directory. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. libiberty/ChangeLog: * make-temp-file.c (try_dir): Check to see if the dir is actually a directory.