aboutsummaryrefslogtreecommitdiff
path: root/libiberty
AgeCommit message (Collapse)AuthorFilesLines
2023-05-08Update ChangeLog and version files for releasereleases/gcc-12.3.0Richard Biener1-0/+4
2023-04-19Daily bump.GCC Administrator1-0/+9
2023-04-18libiberty: Make strstr.c in libiberty ANSI compliantJakub Jelinek1-5/+10
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote: > > On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote: > > The original code in libiberty says "FIXME" and then says it has not been > > validated to be ANSI compliant. However, this patch changes the function to > > match implementations that ARE compliant, and such code is in the public > > domain. > > > > I ran the test results, and there are no test failures. > > Thanks.  This seems to be the standard "simple" strstr implementation.  > There's significantly faster implementations available, but I doubt it's > worth the effort as the version in this file only gets used if there is > no system strstr.c. Except that PR109306 says the new version is non-compliant and is certainly slower than what we used to have. The only problem I see on the old version (sure, it is not very fast version) is that for strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because strchr in that case changed p to point to the last character and then strncmp returned 0. The question reported in PR109306 is whether memcmp is required not to access characters beyond the first difference or not. For all of memcmp/strcmp/strncmp, C17 says: "The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp is determined by the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the objects being compared." but then in memcmp description says: "The memcmp function compares the first n characters of the object pointed to by s1 to the first n characters of the object pointed to by s2." rather than something similar to strncmp wording: "The strncmp function compares not more than n characters (characters that follow a null character are not compared) from the array pointed to by s1 to the array pointed to by s2." So, while for strncmp it seems clearly well defined when there is zero terminator before reaching the n, for memcmp it is unclear if say int memcmp (const void *s1, const void *s2, size_t n) { int ret = 0; size_t i; const unsigned char *p1 = (const unsigned char *) s1; const unsigned char *p2 = (const unsigned char *) s2; for (i = n; i; i--) if (p1[i - 1] != p2[i - 1]) ret = p1[i - 1] < p2[i - 1] ? -1 : 1; return ret; } wouldn't be valid implementation (one which always compares all characters and just returns non-zero from the first one that differs). So, shouldn't we just revert and handle the len == 0 case correctly? I think almost nothing really uses it, but still, the old version at least worked nicer with a fast strchr. Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred because strchr already compared the first character. 2023-04-02 Jakub Jelinek <jakub@redhat.com> PR other/109306 * strstr.c: Revert the 2020-11-13 changes. (strstr): Return s1 if len is 0. (cherry picked from commit 1719fa40c4ee4def60a2ce2f27e17f8168cf28ba)
2023-01-05Daily bump.GCC Administrator1-0/+14
2023-01-04libiberty: Fix C89-isms in configure testsFlorian Weimer2-6/+22
libiberty/ * acinclude.m4 (ac_cv_func_strncmp_works): Add missing int return type and parameter list to the definition of main. Include <stdlib.h> and <string.h> for prototypes. (ac_cv_c_stack_direction): Add missing int return type and parameter list to the definitions of main, find_stack_direction. Include <stdlib.h> for exit prototype. * configure: Regenerate. (cherry picked from commit 885b6660c17fb91980b5682514ef54668e544b02)
2022-08-19Update ChangeLog and version files for releasereleases/gcc-12.2.0Richard Biener1-0/+4
2022-05-06Update ChangeLog and version files for releasereleases/gcc-12.1.0Jakub Jelinek1-0/+4
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.
2021-10-23Daily bump.GCC Administrator1-0/+6
2021-10-22Add install-dvi Makefile targets.Eric Gallager1-1/+19
Closes #102663 ChangeLog: PR other/102663 * Makefile.def: Handle install-dvi target. * Makefile.tpl: Likewise. * Makefile.in: Regenerate. c++tools/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. gcc/ChangeLog: PR other/102663 * Makefile.in: Handle dvidir and install-dvi target. * configure: Regenerate. * configure.ac: Add install-dvi to target_list. gcc/ada/ChangeLog: PR other/102663 * gcc-interface/Make-lang.in: Allow dvi-formatted documentation to be installed. gcc/c/ChangeLog: PR other/102663 * Make-lang.in: Add dummy c.install-dvi target. gcc/cp/ChangeLog: PR other/102663 * Make-lang.in: Add dummy c++.install-dvi target. gcc/d/ChangeLog: PR other/102663 * Make-lang.in: Allow dvi-formatted documentation to be installed. gcc/fortran/ChangeLog: PR other/102663 * Make-lang.in: Allow dvi-formatted documentation to be installed. gcc/lto/ChangeLog: PR other/102663 * Make-lang.in: Add dummy lto.install-dvi target. gcc/objc/ChangeLog: PR other/102663 * Make-lang.in: Add dummy objc.install-dvi target. gcc/objcp/ChangeLog: PR other/102663 * Make-lang.in: Add dummy objc++.install-dvi target. gnattools/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libada/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libcpp/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libdecnumber/ChangeLog: PR other/102663 * Makefile.in: Add dummy install-dvi target. libiberty/ChangeLog: PR other/102663 * Makefile.in: Allow dvi-formatted documentation to be installed.
2021-10-18Daily bump.GCC Administrator1-0/+8
2021-10-17[PATCH] d-demangle: properly skip anonymous symbolsLuís Ferreira2-4/+18
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-15Daily bump.GCC Administrator1-0/+9
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-13Daily bump.GCC Administrator1-0/+5
2021-10-12[PATCH v2] libiberty: d-demangle: remove parenthesis where it is not neededLuís Ferreira1-6/+6
libiberty/ * d-demangle.c (dlang_parse_qualified): Remove redudant parenthesis around lhs and rhs of assignments.
2021-10-02Daily bump.GCC Administrator1-0/+4
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-24Daily bump.GCC Administrator1-0/+10
2021-09-23libiberty: prevent null dereferencing on dlang_typeLuís Ferreira2-2/+5
libiberty/ * d-demangle.c (dlang_Type): Validate MANGLED is nonnull. * testsuite/d-demangle-expected: New test.
2021-09-23libiberty: prevent buffer overflow when decoding user inputLuís Ferreira1-1/+1
libiberty/ * d-demangle.c (dlang_symbol_backref): Ensure strlen of string is less than length computed by dlang_number.
2021-09-02Daily bump.GCC Administrator1-0/+7
2021-09-01libiberty, configure, Darwin: Avoid detecting deprecated sbrk.Iain Sandoe3-25/+35
Darwin provides an implementation of sbrk, which is detected by the configuration process. However, it is deprecated which leads to build warnings. The malloc-based implementation is more suitable. This patch removes sbrk from the functions searched for Darwin. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> libiberty/ChangeLog: * configure: Regenerate. * configure.ac: Do not search for sbrk on Darwin. * xmalloc.c: Do not declare sbrk unless it has been found by configure.
2021-08-30Daily bump.GCC Administrator1-0/+20
2021-08-30libiberty: Add support for demangling local D template declarationsIain Buclaw2-0/+43
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 Buclaw2-13/+31
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 Buclaw2-3/+15
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-08-24Daily bump.GCC Administrator1-0/+5
2021-08-23libiberty, Darwin: Fix a build warning.Iain Sandoe1-1/+1
r12-3005-g220c410162ebece4f missed a cast for the set_32 call. Fixed thus. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> libiberty/ChangeLog: * simple-object-mach-o.c (simple_object_mach_o_write_segment): Cast the first argument to set_32 as needed.
2021-08-19Daily bump.GCC Administrator1-0/+5