aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-10sim: m32r: enable warnings in traps.cMike Frysinger2-4/+0
File should be clean now!
2024-01-10sim: m32r: fixup some of the int<->pointer castsMike Frysinger4-31/+94
The m32r trap code was written for a 32-bit Linux host (and really, one whose Linux ABI matched pretty exactly). This has lead to conversions between integers and pointers which breaks down hard on 64-bit hosts. Clean up some of the functions where possible to avoid unnecessary conversions, use uintptr_t to cast 32-bit target pointers to host pointers in some places, and just stub out a few functions that can't easily be salvaged currently when sizeof(void*) is not 32-bits. This is a bit ugly, but lets us enable warnings for the whole file.
2024-01-10sim: m32r: fix missing break statementMike Frysinger1-0/+1
The ftime syscall should not fallthrough to the sync syscall. Clearly the code was missing a break statement.
2024-01-10sim: m32r: migrate ftime() to clock_gettime()Mike Frysinger1-5/+8
The ftime() function has been deprecated since POSIX-1-2004, and removed in POSIX.1-2008. It's also been deprecated/removed in glibc since 2.33. POSIX has always said the function is not portable, and its return value, timezone, and dstflag fields are unspecified. Even if Linux/glibc & m32r had defined behavior, those aren't the host for the sim runtime. So let's stop using the function and switch to clock_gettime. gnulib already has detection support for it, and it's been around since at least POSIX-1-2004.
2024-01-10sim: m32r: cleanup unused variablesMike Frysinger1-3/+1
We've been building this file with -Wno-error, so clean up unused variable warnings.
2024-01-10sim: igen: add printf attributes to the prototypes tooMike Frysinger1-4/+4
While gcc propagates the printf attribute via the typedef, clang doesn't seem to, so add it to the prototypes themselves too. We still keep it on the prototype for cases where it's used as a variable.
2024-01-10gdbsupport: tighten up libiberty code a bit with dnlMike Frysinger5-17/+7
No functional change here, just touch up generated output slightly. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10sim: build: switch to gdbsupport/libiberty.m4Mike Frysinger5-13/+411
Leverage this common logic to find all the libiberty settings rather than duplicate it ourselves.
2024-01-10sim: ppc: rework defines.h to handle HAVE symbols defined to 0Mike Frysinger2-2/+2
The HAVE_DECL_xxx defines are always defined to 0 or 1. The current defines.h logic assumes every HAVE_xxx symbol is only defined iff it's defined to 1 which causes this to break. Tweak the sed logic to only match defines of 1.
2024-01-10gdb: libiberty: switch to AC_CHECK_DECLS_ONCEMike Frysinger4-177/+211
Only check these decls once in case other m4 macros also look for them. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb: move libiberty.m4 to gdbsupportMike Frysinger5-6/+7
This is used by gdb, gdbsupport, and gdbserver. We want to use it in the sim tree too. Move it to gdbsupport which is meant as the common sharing space for these projects. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-11Automatic date update in version.inGDB Administrator1-1/+1
2024-01-10gprofng: add an examples directoryVladimir Mezentsev8-0/+1115
This directory contains example programs for the user to experiment with. Initially there is one application written in C. The plan is to include more examples, also in other langauges, over time. In addition to the sources and a make file, a sample script how to make a profile is included. There is also a README.md file. gprofng/ChangeLog 2024-01-08 Ruud van der Pas <ruud.vanderpas@oracle.com> * examples: Top level directory. * examples/mxv-pthreads: Example program written in C.
2024-01-10gprofng: 31123 improvements to hardware event implementationVladimir Mezentsev8-247/+293
Our hardware counter profiling is based on perf_event_open(). Our HWC tables are absent for new machines. I have added HWC tables for the following events: PERF_TYPE_HARDWARE, PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes. Did a little cleaning: marked the symbols as static, used Stringbuilder, created a function to read /proc/cpuinfo. gprofng/ChangeLog 2024-01-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/31123 * common/core_pcbe.c: Mark the symbols as static. Add events_generic[]. * common/hwc_cpus.h: Declare a new function read_cpuinfo. * common/hwcdrv.c: Add a new parameter in init_perf_event(). * common/hwcentry.h: Add use_perf_event_type in Hwcentry. * common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type, type, config. * common/hwctable.c: Add a new HWC table generic_list[]. * common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines. * src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc(). Add a new function read_cpuinfo.
2024-01-10Fix AIX catchpoint warning during fork () eventAditya Vidyadhar Kamath1-0/+16
In AIX we were missing some hooks needed to catch a fork () event in rs6000-aix-nat.c. Due to their absence we were returning 1 while we insert the breakpoint/catchpoint location. This patch is a fix to the same.
2024-01-10Sync top level configure and makefilesNick Clifton5-23/+1114
This update brings in the following commits from the gcc mainline: commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f Author: Tom Tromey <tom@tromey.com> Date: Tue Jan 9 06:25:26 2024 -0700 Pass GUILE down to subdirectories When I enable cgen rebuilding in the binutils-gdb tree, the default is to run cgen using 'guile'. However, on my host, guile is guile 2.2, which doesn't work for me -- I have to use guile3.0. This patch arranges to pass "GUILE" down to subdirectories, so I can use 'make GUILE=guile3.0'. commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb Author: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com> Date: Wed Oct 25 13:06:48 2023 +0200 build: Add libgrust as compilation modules Define the libgrust directory as a host compilation module as well as for targets. Disable target libgrust if we're not building target libstdc++. commit 56ca59a03150cf44cea340f58967c990ed6bf43c Author: Lewis Hyatt <lhyatt@gmail.com> Date: Thu Nov 16 11:18:37 2023 -0500 Makefile.tpl: Avoid race condition in generating site.exp from the top level A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of a fresh build directory does not work reliably. That will spawn two independent make processes inside the "gcc" directory, and each of those will attempt to create site.exp if it doesn't exist and will interfere with each other, producing often a corrupted or empty site.exp. Resolve that by making these targets depend on a new phony target which makes sure site.exp is created first before starting the recursive makes. commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1 Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sun Mar 28 14:48:17 2021 +0100 Config,Darwin: Allow for configuring Darwin to use embedded runpath. Recent Darwin versions place contraints on the use of run paths specified in environment variables. This breaks some assumptions in the GCC build. This change allows the user to configure a Darwin build to use '@rpath/libraryname.dylib' in library names and then to add an embedded runpath to executables (and libraries with dependents). The embedded runpath is added by default unless the user adds '-nodefaultrpaths' to the link line. For an installed compiler, it means that any executable built with that compiler will reference the runtimes installed with the compiler (equivalent to hard-coding the library path into the name of the library). During build-time configurations any "-B" entries will be added to the runpath thus the newly-built libraries will be found by exes. Since the install name is set in libtool, that decision needs to be available here (but might also cause dependent ones in Makefiles, so we need to export a conditional). This facility is not available for Darwin 8 or earlier, however the existing environment variable runpath does work there. We default this on for systems where the external DYLD_LIBRARY_PATH does not work and off for Darwin 8 or earlier. For systems that can use either method, if the value is unset, we use the default (which is currently DYLD_LIBRARY_PATH). commit 2551e10038a70901f30b2168e6e3af4536748f3c Author: Sergei Trofimovich <siarheit@google.com> Date: Mon Oct 2 12:08:17 2023 +0100 Makefile.tpl: disable -Werror for feedback stage [PR111663] Without the change profiled bootstrap fails for various warnings on master branch as: $ ../gcc/configure $ make profiledbootstrap ... gcc/genmodes.cc: In function ‘int main(int, char**)’: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] ... gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] The change removes -Werror just like autofeedback does today. commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a Author: Thomas Schwinge <thomas@codesourcery.com> Date: Thu Jun 1 23:07:37 2023 +0200 Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] ..., where we need to use it (separate commits) for build-tree testing, similar to 'gcc/Makefile.in:site.exp': # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation. # They are passed first to allow individual tests to override them. @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp PR testsuite/109951 * Makefile.tpl (BASE_TARGET_EXPORTS): Add 'SYSROOT_CFLAGS_FOR_TARGET'. * Makefile.in: Regenerate.
2024-01-10gas: aarch64: Add system registers for Debug and PMU extensionsSaurabh Jha5-0/+207
This patch adds support for the new AArch64 system registers that are part of the following extensions: * FEAT_DEBUGv8p9 * FEAT_PMUv3p9 * FEAT_PMUv3_SS * FEAT_PMUv3_ICNTR * FEAT_SEBEP
2024-01-10[gdb] Fix assertion failure for checkpoint delete 0Tom de Vries2-0/+25
When doing "checkpoint delete 0" we run into an assertion failure: ... +delete checkpoint 0 inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed. ... Fix this by handling the "pptid == null_ptid" case in delete_checkpoint_command. Tested on x86_64-linux. Approved-By: Kevin Buettner <kevinb@redhat.com> PR gdb/31209 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209
2024-01-10[gdb] Fix info checkpointsTom de Vries2-5/+18
Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info checkpoints command: ... (gdb) info checkpoints^M * 0 process 30570 (main process) at 0x0^M 1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M 2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M 3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M 4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M 5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M 6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M 7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M 8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M 9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M 10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M ... According to the docs, each of these (0-10) is a checkpoint. But the pc address (as well as the file name and line number) is missing for checkpoint 0. Fix this by sampling the pc value for the current process in info_checkpoints_command, such that we have instead: ... * 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M ... Tested on x86_64-linux. Approved-By: Kevin Buettner <kevinb@redhat.com> PR gdb/31211 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211
2024-01-10[gdb] Make variable printed bool in info_checkpoints_commandTom de Vries1-3/+4
While reading info_checkpoints_command, I noticed variable printed: ... const fork_info *printed = NULL; ... for (const fork_info &fi : fork_list) { if (requested > 0 && fi.num != requested) continue; printed = &fi; ... } if (printed == NULL) ... has pointer type, but is just used as bool. Make this explicit by changing the variable type to bool. Tested on x86_64-linux. Approved-By: Kevin Buettner <kevinb@redhat.com>
2024-01-10gdb/symtab: Eliminate deferred_entryTom de Vries3-31/+68
Currently cooked_index entry creation is either: - done immediately if the parent_entry is known, or - deferred if the parent_entry is not yet known, and done later while resolving the deferred entries. Instead, create all cooked_index entries immediately, and keep track of which entries have a parent_entry that needs resolving later using the new IS_PARENT_DEFERRED flag. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb/symtab: Make cooked_index_entry::parent_entry privateTom de Vries3-16/+29
Make cooked_index_entry::parent_entry private, and add member functions to access it. Tested on x86_64-linux and ppc64le-linux. Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb/symtab: Allow changing of added cooked_index entriesTom de Vries2-11/+11
Make cooked_index_storage::add and cooked_index_entry::add return a "cooked_index_entry *" instead of a "const cooked_index_entry *". Tested on x86_64-linux and ppc64le-linux. Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-01-09Fix ASAN failure in DWO codeTom Tromey1-8/+23
Simon pointed out that my recent change to the DWO code caused a failure in ASAN testing. The bug here was I updated the code to use a different search type in the hash table; but then did not change the search code to use htab_find_slot_with_hash. Note that this bug would not be possible with my type-safe hash table series, hint, hint. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-01-10Automatic date update in version.inGDB Administrator1-1/+1
2024-01-09Fix thread-less buildTom Tromey1-4/+4
A user pointed out that the recent background DWARF reader series broke the build when --disable-threading is in use. This patch fixes the problem. I am checking it in. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223
2024-01-09Pass GUILE down to subdirectoriesTom Tromey3-4/+12
When I enable cgen rebuilding in the binutils-gdb tree, the default is to run cgen using 'guile'. However, on my host, guile is guile 2.2, which doesn't work for me -- I have to use guile3.0. This patch arranges to pass "GUILE" down to subdirectories, so I can use 'make GUILE=guile3.0'. * Makefile.in: Rebuild. * Makefile.tpl (BASE_EXPORTS): Add GUILE. (GUILE): New variable. * Makefile.def (flags_to_pass): Add GUILE.
2024-01-09ld: Add --enable-mark-plt configure optionH.J. Lu6-3/+73
Add --enable-mark-plt linker configure option to mark PLT entries with DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by default. * NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt. * config.in: Regenerated. * configure: Likewise. * configure.ac: Add --enable-mark-plt. (DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED. * emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT): Support DEFAULT_LD_Z_MARK_PLT. * emultempl/elf-x86.em (elf_x86_64_before_parse): New function. (LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for x86-64 targets.
2024-01-09elf: Add elf_backend_add_glibc_version_dependencyH.J. Lu7-62/+167
When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation stores the offset of the indirect branch instruction. However, glibc versions which don't have this commit in glibc 2.36: commit f8587a61892cbafd98ce599131bf4f103466f084 Author: H.J. Lu <hjl.tools@gmail.com> Date: Fri May 20 19:21:48 2022 -0700 x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we can ignore their r_addends. Reviewed-by: Fangrui Song <maskray@google.com> won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. Although this commit has been backported to glibc 2.33/2.34/2.35 release branches, it is safer to require glibc 2.36 for such binaries. Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to also add GLIBC_2.36 version dependency for -z mark-plt on the shared C library if it provides a GLIBC_2.XX symbol version. * elflink.c (elf_find_verdep_info): Moved to ... * elf-bfd.h (elf_find_verdep_info): Here. (elf_backend_data): Add elf_backend_add_glibc_version_dependency. (_bfd_elf_link_add_glibc_version_dependency): New function. (_bfd_elf_link_add_dt_relr_dependency): Likewise. * elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): Likewise. (elf_backend_add_glibc_version_dependency): New. * elflink.c (elf_link_add_dt_relr_dependency): Renamed to ... (elf_link_add_glibc_verneed): This. Modified to support other glibc dependencies. (_bfd_elf_link_add_glibc_version_dependency): Likewise. (_bfd_elf_link_add_dt_relr_dependency): Likewise. (bfd_elf_size_dynamic_sections): Call elf_backend_add_glibc_version_dependency instead of elf_link_add_dt_relr_dependency. * elfxx-target.h (elf_backend_add_glibc_version_dependency): New. (elfNN_bed): Add elf_backend_add_glibc_version_dependency. ld/ * testsuite/ld-x86-64/mark-plt-1a.rd: New file. * testsuite/ld-x86-64/mark-plt-1b.rd: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for GLIBC_2.36 dependency.
2024-01-09x86: Don't check R_386_NONE nor R_X86_64_NONEH.J. Lu9-0/+59
Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning relocations. bfd/ * PR ld/31047 * elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE. * elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check R_X86_64_NONE. ld/ * PR ld/31047 * testsuite/ld-i386/i386.exp: Run PR ld/31047 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-i386/pr31047.d: New file. * testsuite/ld-x86-64/pr31047-x32.d: Likewise. * testsuite/ld-x86-64/pr31047.d: Likewise. * testsuite/ld-x86-64/pr31047a.s: Likewise. * testsuite/ld-x86-64/pr31047b.s: Likewise.
2024-01-09Fix two bugs in gdbserver thread name handlingTom Tromey1-3/+6
Simon pointed out that my earlier patch to gdbserver's thread name code: commit 07b3255c3bae7126a0d679f957788560351eb236 Author: Tom Tromey <tom@tromey.com> Date: Thu Jul 13 17:28:48 2023 -0600 Filter invalid encodings from Linux thread names ... introduced a regression. This bug was that the iconv output was not \0-terminated. Looking at it, I found another bug as well -- replace_non_ascii would not \0-terminate, and also would return the wrong pointer This patch fixes both of them. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153
2024-01-09Use unrelocated_addr in dwarf2_base_index_functions::find_per_cuTom Tromey4-12/+14
dwarf2_base_index_functions::find_per_cu is documented as using an unrelocated address. This patch changes the interface to use the unrelocated_addr type, just to be a bit more type-safe. Regression tested on x86-64 Fedora 38.
2024-01-09x86: add missing APX logic to cpu_flags_match()Jan Beulich4-1/+48
As already indicated during review, we can't get away without certain adjustments here: Without these, respective {evex}-prefixed insns are assembled to APX encodings even when APX_F is turned off. While there also extend the respective comment in the opcode table, to explain why this construct is used.
2024-01-09x86: FMA insns aren't eligible to VEX2 encodingJan Beulich8-0/+11
PR gas/31178 In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked that C aliases StaticRounding, and hence build_vex_prefix() now needs to be aware of that aliasing. Disambiguation is easy, as StaticRounding is only ever used together with SAE (hence why the overlaying works in the first place).
2024-01-09PPC64/ELF: adjust comment wrt ABI versionsJan Beulich1-1/+1
While having been moved a couple of times since its introduction in f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"), the wording has always remained the same. In particular ELFv1 and ELFv2 have always been the wrong way round.
2024-01-09Synchronize sourceware version of the libiberty sources with the master gcc ↵Nick Clifton8-31/+342
versions. This brings in the following commits: commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Dec 5 23:32:19 2023 +0100 libiberty: Fix build with GCC < 7 Tobias reported on IRC that the linker fails to build with GCC 4.8.5. In configure I've tried to use everything actually used in the sha1.c x86 hw implementation, but unfortunately I forgot about implicit function declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define and __get_cpuid function defined inline, but it didn't define __get_cpuid_count, which compiled fine (and the configure test is intentionally compile time only) due to implicit function declaration, but then failed to link when linking the linker, because __get_cpuid_count wasn't defined anywhere. The following patch fixes that by using what autoconf uses in AC_CHECK_DECL to make sure the functions are declared. commit 691858d279335eeeeed3afafdf872b1c5f8f4201 Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> Date: Tue Dec 5 11:04:06 2023 +0100 libiberty: Fix pex_unix_wait return type The recent warning patches broke Solaris bootstrap: /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types] 326 | pex_unix_wait, | ^~~~~~~~~~~~~ /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait') While pex_funcs.wait expects a function returning pid_t, pex_unix_wait currently returns int. However, on Solaris pid_t is long for 32-bit, but int for 64-bit. This patches fixes this by having pex_unix_wait return pid_t as expected, and like every other variant already does. Bootstrapped without regressions on i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and x86_64-apple-darwin23.1.0. commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 Author: Jason Merrill <jason@redhat.com> Date: Mon Sep 25 10:15:02 2023 +0100 c++: mangle function template constraints Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and https://github.com/itanium-cxx-abi/cxx-abi/pull/166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. commit f2c52c0dfde581461959b0e2b423ad106aadf179 Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> Date: Thu Nov 30 10:06:23 2023 +0100 libiberty: Disable hwcaps for sha1.o This patch commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Nov 28 13:14:05 2023 +0100 libiberty: Use x86 HW optimized sha1 broke Solaris/x86 bootstrap with the native as: libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ] gccgo: fatal error: Killed signal terminated program go1 As is already done in a couple of other similar cases, this patches disables hwcaps support for libiberty. Initially, this didn't work because config/hwcaps.m4 uses target_os, but didn't ensure it is defined. Tested on i386-pc-solaris2.11 with as and gas. commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Nov 28 13:14:05 2023 +0100 libiberty: Use x86 HW optimized sha1 Nick has approved this patch (+ small ld change to use it for --build-id=), so I'm commiting it to GCC as master as well. If anyone from ARM would be willing to implement it similarly with vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker speedup on those hosts as well, the intent in sha1.c was that sha1_hw_process_bytes, sha1_hw_process_block functions would be defined whenever defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) but the body of sha1_hw_process_block and sha1_choose_process_bytes would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for the other arch support, similarly for any target attributes on sha1_hw_process_block if needed. commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942 Author: Mark Wielaard <mjw@redhat.com> Date: Wed Nov 15 20:27:08 2023 +0100 Regenerate libiberty/aclocal.m4 with aclocal 1.15.1 There is a new buildbot check that all autotool files are generated with the correct versions (automake 1.15.1 and autoconf 2.69). https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen Correct one file that was generated with the wrong version. commit 879cf9ff45d94065d89e24b71c6b27c7076ac518 Author: Brendan Shanks <bshanks@codeweavers.com> Date: Thu Nov 9 21:01:07 2023 -0700 [PATCH v3] libiberty: Use posix_spawn in pex-unix when available. Hi, This patch implements pex_unix_exec_child using posix_spawn when available. This should especially benefit recent macOS (where vfork just calls fork), but should have equivalent or faster performance on all platforms. In addition, the implementation is substantially simpler than the vfork+exec code path. Tested on x86_64-linux. v2: Fix error handling (previously the function would be run twice in case of error), and don't use a macro that changes control flow. v3: Match file style for error-handling blocks, don't close in/out/errdes on error, and check close() for errors. commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450 Author: Jason Merrill <jason@redhat.com> Date: Thu Aug 17 11:36:23 2023 -0400 c++: constrained hidden friends [PR109751] r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all. We were wrongly treating the different instantiations of the same friend template as the same function because maybe_substitute_reqs_for was failing to actually substitute in the case of a non-template friend. But we don't actually need to do the substitution anyway, because [temp.friend] says that such a friend can't be the same as any other declaration. After fixing that, instead of a redefinition error we got an ambiguous overload error, fixed by allowing constrained hidden friends to coexist until overload resolution, at which point they probably won't be in the same ADL overload set anyway. And we avoid mangling collisions by following the proposed mangling for these friends as a member function with an extra 'F' before the name. I demangle this by just adding [friend] to the name of the function because it's not feasible to reconstruct the actual scope of the function since the mangling ABI doesn't distinguish between class and namespace scopes. PR c++/109751
2024-01-09aarch64: ADD FEAT_THE RCWCAS instructions.Srinath Parvathaneni18-139/+2251
This patch adds support for FEAT_THE doubleword and quadword instructions. doubleword insturctions are enabled by "+the" flag whereas quadword instructions are enabled on passing both "+the and +d128" flags. Support for following sets of instructions is added in this patch. Read check write compare and swap doubleword: (rcwcas, rcwcasa, rcwcasal, rcwcasl) Read check write compare and swap quadword: (rcwcasp,rcwcaspa, rcwcaspal, rcwcaspl) Read check write software compare and swap doubleword: (rcwscas, rcwscasa, rcwscasal, rcwscasl) Read check write software compare and swap quadword: (rcwscasp, rcwscaspa, rcwscaspal, rcwscaspl) Read check write atomic bit clear on doubleword: (rcwclr, rcwclra, rcwclral, rcwclrl) Read check write atomic bit clear on quadword: (rcwclrp, rcwclrpa, rcwclrpal, rcwclrpl) Read check write software atomic bit clear on doubleword: (rcwsclr, rcwsclra, rcwsclral, rcwsclrl) Read check write software atomic bit clear on quadword: (rcwsclrp,rcwsclrpa, rcwsclrpal,rcwsclrpl) Read check write atomic bit set on doubleword: (rcwset,rcwseta, rcwsetal,rcwsetl) Read check write atomic bit set on quadword: (rcwsetp,rcwsetpa,rcwsetpal,rcwsetpl) Read check write software atomic bit set on doubleword: (rcwsset,rcwsseta,rcwssetal,rcwssetl) Read check write software atomic bit set on quadword: (rcwssetp,rcwssetpa,rcwssetpal,rcwssetpl) Read check write swap doubleword: (rcwswp,rcwswpa,rcwswpal,rcwswpl) Read check write swap quadword: (rcwswpp,rcwswppa, rcwswppal,rcwswppl) Read check write software swap doubleword: (rcwsswp,rcwsswpa,rcwsswpal,rcwsswpl) Read check write software swap quadword: (rcwsswpp,rcwsswppa,rcwsswppal,rcwsswppl)
2024-01-09aarch64: Regenerate aarch64-*-2.c filesVictor Do Nascimento3-2407/+2454
2024-01-09arch64: Add optional operand register pair support testsVictor Do Nascimento5-0/+57
Add tests to cover the full range of behaviors observed around optional register operands for the `tlbip' and `sysp' instructions, namely: * Not all `tlbip' operations take GPR operands. When this is the case, we should check that neither optional operand was supplied. * When a `tlbip' operation is labeled with the `F_HASXT' flag, xzr is not a valid optional operand. In such case, at least the fist optional register needs to be specified with a non-xzr value. * The first operand for both insns should be either xzr or an even-numbered register (n % 2 == 0). In the former scenario, the second operand should default to xzr too, while in the latter, it should default to n + 1.
2024-01-09aarch64: Add support for 128-bit system register mrrs and msrr insnsVictor Do Nascimento10-5/+89
With the addition of 128-bit system registers to the Arm architecture starting with Armv9.4-a, a mechanism for manipulating their contents is introduced with the `msrr' and `mrrs' instruction pair. These move values from one such 128-bit system register into a pair of contiguous general-purpose registers and vice-versa, as for example: msrr ttlb0_el1, x0, x1 mrrs x0, x1, ttlb0_el1 This patch adds the necessary support for these instructions, adding checks for system-register width by defining a new operand type in the form of `AARCH64_OPND_SYSREG128' and the `aarch64_sys_reg_128bit_p' predicate, responsible for checking whether the requested system register table entry is marked as implemented in the 128-bit mode via the F_REG_128 flag.
2024-01-09aarch64: Add TLBIP testsVictor Do Nascimento2-0/+259
2024-01-09aarch64: Add xs variants of tlbip operandsVictor Do Nascimento2-0/+125
The 2020 Architecture Extensions to the Arm A-profile architecture added FEAT_XS, the XS attribute feature, giving cores the ability to identify devices which can be subject to long response delays. TLB invalidate (TLBI) operations and barriers can also be annotated with this attribute[1]. With the introduction of the 128-bit translation tables with the Armv8.9-a/Armv9.4-a Translation Hardening Extension, a series of new TLB invalidate operations are introduced which make use of this extension. These are added to aarch64_sys_regs_tlbi[] for use with the `tlbip' insn. [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020
2024-01-09aarch64: Implement TLBIP 128-bit instructionVictor Do Nascimento3-0/+5
The addition of 128-bit page table descriptors and, with it, the addition of 128-bit system registers for these means that special "invalidate translation table entry" instructions are needed to cope with the new 128-bit model. This is introduced with the `tlbpi' instruction, implemented here.
2024-01-09aarch64: Create QL_SRC_X2 and QL_DEST_X2 qualifier macrosVictor Do Nascimento1-0/+12
Some 128-bit system operations (mrrs, msrr, tlbip, and sysp) take two qualified operands and one of unqualified type (e.g. system register name, tlbip operation). This creates the need for adequate qualifiers to handle this. This patch therefore introduces the `QL_SRC_X2' and `QL_DST_X2' qualifier specifiers, which expand to `QLF3(NIL,X,X)' and `QLF3(X,X,NIL)', respectively.
2024-01-09aarch64: Apply narrowing of allowed immediate values for SYSPVictor Do Nascimento6-3/+41
While CRn and CRm fields in the SYSP instruction are 4-bit wide and are thus able to accommodate values in the range 0-15, the specifications for the SYSP instructions limit their ranges to 8-9 for CRm and 0-7 in the case of CRn. This led to the need to signal in some way to the operand parser that a given operand is under special restrictions regarding its use. This is done via the new `F_OPD_NARROW' flag, indicating a narrowing in the range of operand values for fields in the instruction tagged with the flag. The flag is then used in `parse_operands' when the instruction is assembled, but needs not be taken into consideration during disassembly.
2024-01-09aarch64: Add support for the SYSP 128-bit system instructionVictor Do Nascimento5-3/+20
Mirroring the use of the `sys' - System Instruction assembly instruction, this implements its 128-bit counterpart, `sysp'. This optionally takes two contiguous general-purpose registers starting at an even number or, when these are omitted, by default sets both of these to xzr. Syntax: sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}
2024-01-09aarch64: Add support for optional operand pairsVictor Do Nascimento2-3/+28
Two of the instructions added by the `+d128' architectural extension add the flexibility to have two optional operands. Prior to the addition of the `tlbip' and `sysp' instructions, no mnemonic allowed more than one such optional operand. With `tlbip' as an example, some TLBIP instruction names do not allow for any optional operands, while others allow for both to be optional. In the latter case, it is possible that either the second operand alone is omitted or both operands are omitted. Therefore, a considerable degree of flexibility needed to be added to the way operands were parsed. It was, however, possible to achieve this with relatively few changes to existing code. it is noteworthy that opcode flags specifying the optional operand number are non-orthogonal. For example, we have: #define F_OPD1_OPT (2 << 12) : 0b10 << 12 #define F_OPD2_OPT (3 << 12) : 0b11 << 12 such that by virtue of the observation that (F_OPD1_OPT | F_OPD2_OPT) == F_OPD2_OPT it is impossible to mark both operands 1 and 2 as optional for an instruction and it is assumed that a maximum of 1 operand can ever be optional. This is not overly-problematic given that, for optional pairs, the second optional operand is always found immediately after the first. Thus, it suffices for us to flag that there is a second optional operand. With this fact, we can infer its position in the mnemonic from the position of the first (e.g. if the second operand in the mnemonic is optional, we know the third is too). We therefore define the `F_OPD_PAIR_OPT' flag and calculate its position in the mnemonic from the value encoded by the `F_OPD<n>_OPT' flag. Another observation is that there is a tight coupling between default values assigned to the two registers when one (or both) are omitted from the mnemonic. Namely, if Xt1 has a value of 0x1f (the zero register is specified), Xt2 defaults to the same value, otherwise Xt2 will be assigned Xt + 1. This meant that where you have default value validation, in checking the second optional operand's value, it is also necessary to look at the value assigned to the previously-processed operand value before deciding its validity. Thus `process_omitted_operand' needs not only access to its `operand' argument, but also to the global `inst' struct.
2024-01-09aarch64: Add support for xzr register in register pair operandsVictor Do Nascimento5-4/+26
Analysis of the allowed operand values for `sysp' and `tlbip' reveals a significant departure from the allowed behavior for operand register pairs (hitherto labeled AARCH64_OPND_PAIRREG) observed for other insns in this category. For instructions `casp', `mrrs' and `msrr' the register pair must always start at an even index and the second register in the pair is the index + 1. This precludes the use of xzr as the first register, given it corresponds to register number 31. This is different in the case of `sysp' and `tlbip', however. These allow the use of xzr and, where the first operand in the pair is omitted, this is the default value assigned to it. When this operand is assigned xzr, it is expected that the second operand will likewise take on a value of xzr. These two instructions therefore "break" two rules of register pairs: * The first of the two registers is odd-numbered. * The index of the second register is equal to that of the first, and not n+1. To allow for this departure from hitherto standard behavior, we extend the functionality of the assembler by defining an extension of the AARCH64_OPND_PAIRREG, called AARCH64_OPND_PAIRREG_OR_XZR. It is used in defining `sysp' and `tlbip' and allows `operand_general_constraint_met_p' to allow the pair to both take on the value of xzr.
2024-01-09aarch64: Expand maximum number of operands from 5 to 6Victor Do Nascimento2-1/+3
Given the introduction of the new Armv9.4-a `sysp' insn using the following syntax: sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>} and by extension the need to encode 6 assembly operands, extend Binutils to handle instructions taking 6 operands, up from a previous maximum of 5.
2024-01-09aarch64: Add +d128 architectural feature supportVictor Do Nascimento4-0/+12
Indicating the presence of the Armv9.4-a features concerning 128-bit Page Table Descriptors, 128-bit System Registers and Instructions, the "+d128" architectural extension flag is added to the list of possible -march options in Binutils, together with the necessary macro for encoding d128 instructions.
generated by cgit v1.1 at 2024-10-10 08:49:59 +0000