[PATCH] libgcc: Fix eh_frame fast path in find_fde_tail

The eh_frame value is only used by linear_search_fdes, not the binary search directly in find_fde_tail, so the bug is not immediately apparent with most programs. Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc: Special-case BFD ld unwind table encodings in find_fde_tail"). [I'd ap

Re: [RFC] Add stdckdint.h header for C23

* Paul Eggert: > I don't see how you could implement __has_include_next() > for arbitrary non-GCC compilers, which is what we'd need for glibc > users. This is not a requirement for glibc in general. For example, only works with compilers to which it has been ported. Thanks, Florian

[PATCH releases/gcc-13 2/2] libgcc: Fix -Wint-conversion warning in find_fde_tail

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path in find_fde_tail"). libgcc/ PR libgcc/110179 * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid implicit conversion of pointer value to integer. (cherry picked from commit 104b09005229ef48a79a33

[PATCH releases/gcc-13 1/2] libgcc: Fix eh_frame fast path in find_fde_tail

The eh_frame value is only used by linear_search_fdes, not the binary search directly in find_fde_tail, so the bug is not immediately apparent with most programs. Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc: Special-case BFD ld unwind table encodings in find_fde_tail"). libgcc/

Re: Intel AVX10.1 Compiler Design and Support

* Richard Biener via Gcc-patches: > I don’t think we can realistically change the ABI. If we could > passing them in two 256bit registers would be possible as well. > > Note I fully expect intel to turn around and implement 512 bits on a > 256 but data path on the E cores in 5 years. And it will

Re: Intel AVX10.1 Compiler Design and Support

* Hongtao Liu: > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote: >> Aiui these ABI levels were intended to be incremental, i.e. higher versions >> would include everything earlier ones cover. Without such a guarantee, how >> would you propose compatibility checks to be implemented in a way Cor

Re: [gcc r13-7720] x86: Update model values for Raptorlake.

* Lili Cui via Gcc-cvs: > https://gcc.gnu.org/g:0fa76e35a5f9e141c08fdf151380f2f9689101c7 > > commit r13-7720-g0fa76e35a5f9e141c08fdf151380f2f9689101c7 > Author: Cui, Lili > Date: Mon Aug 14 02:06:00 2023 + > > x86: Update model values for Raptorlake. > > Update model values for

[PATCH] libgcc: Fix -Wint-conversion warning in find_fde_tail

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path in find_fde_tail"). libgcc/ PR libgcc/110179 * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid implicit conversion of pointer value to integer. --- libgcc/unwind-dw2-fde-dip.c | 2 +- 1 file c

[PATCH] aarch64: Fix warnings during libgcc build

libgcc/ * config/aarch64/aarch64-unwind.h (aarch64_cie_signed_with_b_key): Add missing const qualifier. Cast from const unsigned char * to const char *. Use __builtin_strchr to avoid an implicit function declaration. * config/aarch64/linux-unwind.h (aarch6

[PATCH] m68k: Avoid implicit function declaration in libgcc

libgcc/ * config/m68k/fpgnulib.c (__cmpdf2): Declare. --- libgcc/config/m68k/fpgnulib.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libgcc/config/m68k/fpgnulib.c b/libgcc/config/m68k/fpgnulib.c index fe41edf26aa..d5c3411e947 100644 --- a/libgcc/config/m68k/fpgnulib.c +++ b/libgcc

[PATCH] csky: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/csky/linux-unwind.h (csky_fallback_frame_state): Add missing cast. --- libgcc/config/csky/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/csky/linux-unwind.h b/libgcc/config/csky/linux-unwind.h index 66b2a44e047..

[PATCH] arc: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/arc/linux-unwind.h (arc_fallback_frame_state): Add missing cast. --- libgcc/config/arc/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/arc/linux-unwind.h b/libgcc/config/arc/linux-unwind.h index 0292e22ed1b..dec942

[PATCH] or1k: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/or1k/linux-unwind.h (or1k_fallback_frame_state): Add missing cast. --- libgcc/config/or1k/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/or1k/linux-unwind.h b/libgcc/config/or1k/linux-unwind.h index aa873791daa..

[PATCH] riscv: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/riscv/linux-unwind.h (riscv_fallback_frame_state): Add missing cast. --- libgcc/config/riscv/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/riscv/linux-unwind.h b/libgcc/config/riscv/linux-unwind.h index 931c2f27

Re: [PATCH] aarch64: Fix warnings during libgcc build

* Richard Earnshaw: > On 11/07/2023 10:37, Florian Weimer via Gcc-patches wrote: >> libgcc/ >> * config/aarch64/aarch64-unwind.h >> (aarch64_cie_signed_with_b_key): >> Add missing const qualifier. Cast from const unsigned char * >> to const char

Re: [PATCH] improve warning suppression for inlined functions (PR 98465, 98512)

* Martin Sebor via Gcc-patches: > This patch depends on the fix for PR 98664 (already approved but > not yet checked in). I've tested it on x86_64-linux. > > To avoid fallout I tried to keep the changes to a minimum, and > so the design isn't as robust as I'd like it ultimately to be. > I plan to

Re: [PATCH] improve warning suppression for inlined functions (PR 98465, 98512)

* Martin Sebor: > On 1/21/21 10:34 AM, Florian Weimer wrote: >> * Martin Sebor via Gcc-patches: >> >>> This patch depends on the fix for PR 98664 (already approved but >>> not yet checked in). I've tested it on x86_64-linux. >>> >>> To avoid fallout I tried to keep the changes to a minimum, and

Re: [PATCH] rs6000: Fix MMA API - Add support for compatibility built-ins

* Peter Bergner via Gcc-patches: > The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and > __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and > __builtin_vsx_disassemble_pair respectively. It's too late to remove the > old names, so this patch adds s

Re: [PATCH] rs6000: Fix MMA API - Add support for compatibility built-ins

* Peter Bergner: > On 2/5/21 4:28 AM, Florian Weimer wrote: >> * Peter Bergner via Gcc-patches: >> >>> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and >>> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and >>> __builtin_vsx_disassemble_pair res

Re: [PATCH] improve warning suppression for inlined functions (PR 98465, 98512)

* Jeff Law via Gcc-patches: > I'd lean towards deferring to gcc12 stage1 given the libstdc++ hack is > in place.  That does mean that glibc will need to work around the > instance they've stumbled over in ppc's rawmemchr. We'll need to work around this in the glibc build, too. I'll check if the

Re: [PATCH 0/2] Rework adding Power10 IEEE 128-bit min, max, and conditional move

* Michael Meissner via Gcc-patches: > These patches are my latest versions of the patches to add IEEE 128-bit min, > max, and conditional move to GCC. They correspond to the earlier patches #3 > and #4 (patches #1 and #2 have been installed). Is this about IEEE min or IEEE minimum? My understan

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

* Alejandro Colomar via Libc-alpha: > +the compiler is able to generate efficient code for 128-bit arithmetic". Stray "? > +.PP > +See also the > +.IR intmax_t , > +.IR int N _t I think it's surprising that intmax_t can be smaller than __int128 (and usually is, I think), so that's probably wort

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

* Paul Eggert: > On 10/2/20 12:01 PM, Alejandro Colomar wrote: >> If you propose not to document the stdint types either, > > This is not a stdint.h issue. __int128 is not in stdint.h and is not a > system data type in any real sense; it's purely a compiler > issue. Besides, do we start repeating

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

* Michael Kerrisk: > Hi Florian, > > On 10/5/20 9:12 AM, Florian Weimer wrote: >> * Paul Eggert: >> >>> On 10/2/20 12:01 PM, Alejandro Colomar wrote: If you propose not to document the stdint types either, >>> >>> This is not a stdint.h issue. __int128 is not in stdint.h and is not a >>> sys

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

* Jakub Jelinek: > The disadvantage of the patch is that touching reg[x].loc and how[x] > now means 2 cachelines rather than one as before, and I admit beyond > bootstrap/regtest I haven't benchmarked it in any way. Florian, could > you retry whatever you measured to get at the 40% of time spent

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

* Jakub Jelinek: > On Mon, Sep 19, 2022 at 11:25:13AM +0200, Florian Weimer wrote: >> * Jakub Jelinek: >> >> > The disadvantage of the patch is that touching reg[x].loc and how[x] >> > now means 2 cachelines rather than one as before, and I admit beyond >> > bootstrap/regtest I haven't benchmarke

Re: [PATCH] eliminate mutex in fast path of __register_frame

* Thomas Neumann: > +#ifndef HIDE_EXPORTS > +#pragma GCC visibility push(default) > +#endif All defined functions are static, right? Then this isn't necessary. > +// Common logic for version locks > +struct version_lock > +{ > + // The lock itself > + uintptr_t version_lock; > +}; version_lo

Re: [PATCH] eliminate mutex in fast path of __register_frame

* Thomas Neumann: >>> +// Common logic for version locks >>> +struct version_lock >>> +{ >>> + // The lock itself >>> + uintptr_t version_lock; >>> +}; >> version_lock must not overflow, right? This means we need a wider >> counter on 32-bit, too. glibc contains a 62-bit counter that it uses >

[PATCH] libgcc: Fix _Unwind_Find_FDE for missing unwind data with glibc 2.35

_dl_find_object returns success even if no unwind information has been found, and dlfo_eh_frame is NULL. libgcc/ChangeLog: PR libgcc/104207 * unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add NULL check. --- libgcc/unwind-dw2-fde-dip.c | 2 +- 1 file changed, 1 insertion(+), 1 deleti

Re: [PATCH 3/3] elf: Add _dl_find_eh_frame function

* Adhemerval Zanella via Libc-alpha: > However the code is somewhat complex and I would like to have some feedback > if gcc will be willing to accept this change (I assume it would require > this code merge on glibc beforehand). There's a long review queue on the GCC side due to the stage1 close.

Re: [PATCH 1/3] nptl: Extract from pthread_cond_common.c

* Jakub Jelinek: > On Wed, Nov 03, 2021 at 05:27:42PM +0100, Florian Weimer wrote: >> + /* S3. See __condvar_load_64_relaxed. */ > > Shouldn't that be See __atomic_wide_counter_load_relaxed ? I'm going to fix the stale reference, thanks. >> + if (((l >> 31) > 0) && ((h >> 31) > 0)) > > A

Re: [PATCH 3/3] elf: Add _dl_find_eh_frame function

* Jakub Jelinek: > On Wed, Nov 03, 2021 at 05:28:02PM +0100, Florian Weimer wrote: >> This function is similar to __gnu_Unwind_Find_exidx as used on arm. >> It can be used to speed up the libgcc unwinder. > > I'm little bit worried that this trades the speed of exceptions for > speed of dlopen/dlc

Re: [PATCH 3/3] elf: Add _dl_find_eh_frame function

* Jakub Jelinek: > dl_iterate_phdr is declared in link.h and without the _ prefix, shouldn't > dl_find_eh_frame follow the suit and be declared in the same header and > also without the prefix? We need to use the _ prefix due to this bug: dl_iterate_phdr namespace violation

Re: [PATCH 3/4] libgcc: Split FDE search code from PT_GNU_EH_FRAME lookup

* Jakub Jelinek: > On Wed, Nov 03, 2021 at 05:28:48PM +0100, Florian Weimer wrote: >> @@ -383,12 +376,34 @@ _Unwind_IteratePhdrCallback (struct dl_phdr_info >> *info, size_t size, void *ptr) >> # endif >> #endif >> >> - _Unwind_Ptr dbase = unw_eh_callback_data_dbase (data); >> + return 1; >

[PATCH v2] elf: Add _dl_find_object function

I have reword the previous patch to make the interface more generally useful. Since there are now four words in the core arrays, I did away with the separate base address array. (We can bring it back in the future if necessary.) I fixed a bug in the handling of proxy map (by not copying proxy ma

Re: [PATCH 4/4] libgcc: Use _dl_find_eh_frame in _Unwind_Find_FDE

* Jakub Jelinek: >> +/* Fallback declaration for old glibc headers. DL_FIND_EH_FRAME_DBASE is >> used >> + as a proxy to determine if declares _dl_find_eh_frame. */ >> +#if defined __GLIBC__ && !defined DL_FIND_EH_FRAME_DBASE >> +#if NEED_DBASE_MEMBER >> +void *_dl_find_eh_frame (void *__pc,

Re: [PATCH v2] elf: Add _dl_find_object function

* Jakub Jelinek: > On Thu, Nov 25, 2021 at 09:35:14PM +0100, Florian Weimer wrote: >> +struct dl_find_object >> +{ >> + unsigned long long int dlfo_flags;/* Currently 0. */ >> + void *dlfo_map_start; /* Beginning of mapping containing >> address. */ >> + void *dlfo_map_end

Re: [PATCH] elf: Add __libc_get_static_tls_bounds [BZ #16291]

* Fāng-ruì Sòng: > PING^3 I think the core issue with this patch is like this: * I do not want to commit glibc to a public API that disallows future changes to the way we allocate static TLS. While static TLS objects cannot move in memory, the extent of the static TLS area (minimum and ma

Re: [PATCH] Fix alignment of stack slots for overaligned types [PR103500]

* Alex Coplan via Gcc-patches: > Bootstrapped and regtested on aarch64-linux-gnu, x86_64-linux-gnu, and > arm-linux-gnueabihf: no regressions. > > I'd appreciate any feedback. Is it OK for trunk? Does this need an ABI warning? Thanks, Florian

Re: [committed] libstdc++: Optimize ref-count updates in COW std::string

* Jonathan Wakely via Libstdc: > diff --git a/libstdc++-v3/include/bits/cow_string.h > b/libstdc++-v3/include/bits/cow_string.h > index ced395b80b8..4fae1d02981 100644 > --- a/libstdc++-v3/include/bits/cow_string.h > +++ b/libstdc++-v3/include/bits/cow_string.h > @@ -105,7 +105,7 @@ _GLIBCXX_BEGI

[PATCH v3] elf: Add _dl_find_object function

It can be used to speed up the libgcc unwinder, and the internal _dl_find_dso_for_object function (which is used for caller identification in dlopen and related functions, and in dladdr). _dl_find_object is in the internal namespace due to bug 28503. If libgcc switches to _dl_find_object, this nam

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

* Jonathan Wakely via Libstdc: > If necessary we could keep the terminate-on-cancellation behaviour as > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 > and export the new behaviour as @@GLIBCXX_3.4.30, although this patch > doesn't do that. Note that if this fix escape

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

* Jonathan Wakely: > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > wrote: > > * Jonathan Wakely via Libstdc: > > > If necessary we could keep the terminate-on-cancellation behaviour as > > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 > > and export t

[PATCH] libgcc: Move cfa_how into potential padding in struct frame_state_reg_info

On many architectures, there is a padding gap after the how array member, and cfa_how can be moved there. This reduces the size of the struct and the amount of memory that uw_frame_state_for has to clear. There is no measurable performance benefit from this on x86-64 (even though the memset goes

[PATCH] libgcc: Special-case BFD ld unwind table encodings in find_fde_tail

BFD ld (and the other linkers) only produce one encoding of these values. It is not necessary to use the general read_encoded_value_with_base decoding routine. This avoids the data-dependent branches in its implementation. libgcc/ * unwind-dw2-fde-dip.c (find_fde_tail): Special-case enc

[PATCH] libgcc: Mostly vectorize CIE encoding extraction for FDEs

"zR" and "zPLR" are the most common augmentations. Use a simple SIMD-with-in-a-register technique to check for both augmentations, and that the following variable-length integers have length 1, to get more quickly at the encoding field. libgcc/ * unwind-dw2-fde.c (get_cie_encoding_slow):

Re: [PATCH] libgcc: Mostly vectorize CIE encoding extraction for FDEs

* Richard Biener: > On Mon, Oct 17, 2022 at 3:01 PM Florian Weimer via Gcc-patches > wrote: >> >> "zR" and "zPLR" are the most common augmentations. Use a simple >> SIMD-with-in-a-register technique to check for both augmentations, >> and that

[PATCH] libsanitizer: Avoid implicit function declaration in configure test

libsanitizer/ * configure.ac (check for necessary platform features): Include for syscall prototype. * configure: Regenerate. --- libsanitizer/configure| 5 +++-- libsanitizer/configure.ac | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/libsan

[PATCH] libiberty: Fix C89-isms in configure tests

libiberty/ * acinclude.m4 (check for working strncmp): Add missing int return type and parameter list to the definition of main. Include for string functions. Avoid calling undeclared exit function. (stack direction for C alloca): Avoid calling undeclared

Re: [PATCH] libiberty: Fix C89-isms in configure tests

* Jakub Jelinek: > On Tue, Oct 18, 2022 at 12:05:49PM +0200, Florian Weimer via Gcc-patches > wrote: >> libiberty/ >> >> * acinclude.m4 (check for working strncmp): Add missing >> int return type and parameter list to the definition of main. >>

[PATCH v2] libiberty: Fix C89-isms in configure tests

libiberty/ * acinclude.m4 (ac_cv_func_strncmp_works): Add missing int return type and parameter list to the definition of main. Include and for prototypes. (ac_cv_c_stack_direction): Add missing int return type and parameter list to the definitions of

Re: [PATCH] libiberty: Fix C89-isms in configure tests

* Jakub Jelinek: > On Tue, Oct 18, 2022 at 04:06:17PM +0200, Florian Weimer wrote: >> By the way, the stack direction test currently gives incorrect results >> on x86-64 due to -O2 and address comparison of unrelated objects. I >> assume this doesn't matter because we don't use it on compilers th

Re: C2x features status

* Arsen Arsenović: > On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote: >> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca >> Author: Joseph Myers >> Date: Wed Sep 7 13:56:25 2022 + >> >> c: New C2x keywords >> >> which says: >> >> As with the removal of unprot

Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

* Greg Kroah-Hartman: > On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote: >> But from your side what do we have? Just direct NAKs without much >> explanation. The only one who gave some explanation was Greg, and he >> vaguely pointed to Linus's comments about it in the past, wit

Re: [PATCH] x86: Document -mno-cet-switch

* H. J. Lu via Gcc-patches: > When -fcf-protection=branch is used, the compiler will generate jump > tables where the indirect jump is prefixed with the NOTRACK prefix, so > it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the > NOTRACK specific enable bit must be set, what ren

Re: [PATCH] x86: Document -mno-cet-switch

* H. J. Lu: > On Wed, May 11, 2022 at 1:12 AM Florian Weimer wrote: >> >> * H. J. Lu via Gcc-patches: >> >> > When -fcf-protection=branch is used, the compiler will generate jump >> > tables where the indirect jump is prefixed with the NOTRACK prefix, so >> > it can jump to non-ENDBR targets. Yet

Re: [PATCH] x86: Document -mno-cet-switch

* H. J. Lu: >> >> > Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect >> >> > jump. Document -mno-cet-switch to turn off CET instrumentation on jump >> >> > tables for switch statements. >> >> >> >> Of course, that is a slight regression in security hardening. >> >> >> >> Q

Re: [PATCH] x86: Document -mno-cet-switch

* H. J. Lu: >> NOTRACK avoids the need for ENDBR instructions, right? That's a >> hardening improvement, so it should be used by default. > > NOTRACK weakens IBT since it disables IBT on the indirect jump instruction. > GCC uses it in the jump table to avoid ENDBR. Typical jump table code looks

Re: [PATCH] x86: Document -mno-cet-switch

* H. J. Lu: > On Wed, May 11, 2022 at 11:45 AM Florian Weimer wrote: >> >> * H. J. Lu: >> >> >> NOTRACK avoids the need for ENDBR instructions, right? That's a >> >> hardening improvement, so it should be used by default. >> > >> > NOTRACK weakens IBT since it disables IBT on the indirect jump i

Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain

* Christoph Müllner via Binutils: > I'd like to add two points to this topic and raise two questions. > > 1) Accepting vendor extensions = avoidance of fragmentation > > RISC-V implementors are actively encouraged to implement their > own ISA extensions. To avoid fragmentation in the SW ecosystem

Re: [PATCH v2] x86: Document -mcet-switch

* H. J. Lu: > How about this? > > @item -mcet-switch > @opindex mcet-switch > By default, CET instrumentation is turned off on switch statements that > use a jump table and indirect branch track is disabled. Maybe add here: “Since jump tables are stored in read-only memory, this does not result i

[PATCH 0/3] Add _dl_find_eh_frame function for unwinder optimization

This patch series implements a new function, _dl_find_eh_frame, for use by in-process unwinders. The new function is lock-free and async-signal-safe, and it scales logarithmically with the number of shared objects in the process. It does not write to global data at all, unlike the current libgcc

[PATCH 1/3] nptl: Extract from pthread_cond_common.c

And make it an installed header. This addresses a few aliasing violations (which do not seem to result in miscompilation due to the use of atomics), and also enables use of wide counters in other parts of the library. The debug output in nptl/tst-cond22 has been adjusted to print the 32-bit value

[PATCH 2/3] elf: Introduce GLRO (dl_libc_freeres), called from __libc_freeres

--- elf/Makefile | 2 +- elf/dl-libc_freeres.c | 24 elf/rtld.c | 1 + malloc/set-freeres.c | 5 + sysdeps/generic/ldsodefs.h | 7 +++ 5 files changed, 38 insertions(+), 1 deletion(-) create mode 100644 elf/dl-libc_free

[PATCH 3/3] elf: Add _dl_find_eh_frame function

This function is similar to __gnu_Unwind_Find_exidx as used on arm. It can be used to speed up the libgcc unwinder. --- NEWS | 4 + bits/dlfcn_eh_frame.h | 33 + dlfcn/Makefile| 2 +- dlfcn/dlfcn.

[PATCH 0/4] Use _dl_find_eh_frame to locate DWARF EH data in the unwinder

This is the GCC side of the patch series. To simplify testing, a weak reference to _dl_find_eh_frame is used to enable this feature when running on newer glibc even if built for older glibc. The first three patches are cleanups/refactorings to simplify the actual change in the last patch. Benchm

[PATCH 1/4] libgcc: Remove tbase member from struct unw_eh_callback_data

It is always a null pointer. libgcc/ChangeLog * unwind-dw2-fde-dip.c (struct unw_eh_callback_data): Remove tbase member. (base_from_cb_data): Adjust. (_Unwind_IteratePhdrCallback): Likewise. (_Unwind_Find_FDE): Likewise. --- libgcc/unwind-dw2-fde-dip.c | 8

[PATCH 2/4] libgcc: Remove dbase member from struct unw_eh_callback_data if NULL

Only i386 and nios2 need this member at present. libgcc/ChangeLog * unwind-dw2-fde-dip.c (NEED_DBASE_MEMBER): Define. (struct unw_eh_callback_data): Make dbase member conditional. (unw_eh_callback_data_dbase): New function. (base_from_cb_data): Simplify for the non

[PATCH 3/4] libgcc: Split FDE search code from PT_GNU_EH_FRAME lookup

This allows switching to a different implementation for PT_GNU_EH_FRAME lookup in a subsequent commit. This moves some of the PT_GNU_EH_FRAME parsing out of the glibc loader lock that is implied by dl_iterate_phdr. However, the FDE is already parsed outside the lock before this change, so this do

[PATCH 4/4] libgcc: Use _dl_find_eh_frame in _Unwind_Find_FDE

libgcc/ChangeLog * unwind-dw2-fde-dip.c (USE_DL_FIND_EH_FRAME) (DL_FIND_EH_FRAME_CONDITION): New macros. [__GLIBC__ && !DL_FIND_EH_FRAME_DBASE] (_dl_find_eh_frame): Declare weak function. (_Unwind_Find_FDE): Call _dl_find_eh_frame if available. --- libgcc/u

Invalid -Wstringop-overread warning for valid POSIX constructs

This code: #include #include void f (pthread_key_t key) { pthread_setspecific (key, MAP_FAILED); } Results in a warning: t.c: In function ‘f’: t.c:7:3: warning: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Wstringop-overread] 7 | pthread_setspecific (key, MAP_FAILED

Re: Invalid -Wstringop-overread warning for valid POSIX constructs

* Martin Sebor: > Thanks for the reminder. I have not forgotten about this. > I agreed in our discussion and in the GCC bug report where this > came up (PR 101751) that the GCC logic here is wrong and should > be relaxed. I consider it a GCC bug so I plan to make the change > in the bug fixing s

[RFC PATCH] Implement #pragma GCC noexpand

This can be used to avoid excessive __ mangling of identifiers merely to guard against accidental macro expansion. (Identifiers in the global scope or with external linkage may still need mangling.) In order to support -fdirectives-only without introducing new line change flags, #include is not p

Re: [PATCH 1/5] libstdc++: Import the fast_float library

* Patrick Palka via Libstdc: > This copies the fast_float library[1] into the compiled-in library > sources. We're going to use this library in our floating-point > std::from_chars implementation for faster and more portable parsing of > binary32/64 decimal strings. > > [1]: https://github.com/fa

Re: [PATCH 1/5] libstdc++: Import the fast_float library

* Jonathan Wakely: > On Tue, 16 Nov 2021 at 08:01, Florian Weimer wrote: >> >> * Patrick Palka via Libstdc: >> >> > This copies the fast_float library[1] into the compiled-in library >> > sources. We're going to use this library in our floating-point >> > std::from_chars implementation for faster

Re: [PATCH][libsanitizer]: Guard cyclades inclusion in sanitizer

* Tamar Christina via Gcc-patches: > Hi All, > > libsanitizer: Guard cyclades inclusion in sanitizer > > The Linux kernel has removed the interface to cyclades from > the latest kernel headers[1] due to them being orphaned for the > past 13 years. Nit: The commit subject doesn't match the patch b

[PATCH] libgomp: Include early to avoid link failure with glibc 2.34

is included indirectly in the #pragma GCC visibility hidden block. With glibc 2.34, needs a declaration of the sysconf function, and including it under hidden visibility turns other calls to sysconf into hidden references, leading to a linker failure. libgomp/ChangeLog: * libgomp.h: In

Re: [PATCH] libgomp: Include early to avoid link failure with glibc 2.34

* Florian Weimer: > is included indirectly in the #pragma GCC visibility hidden > block. With glibc 2.34, needs a declaration of the sysconf > function, and including it under hidden visibility turns other calls > to sysconf into hidden references, leading to a linker failure. > > libgomp/Chang

Re: [PATCH] libgomp: Include early to avoid link failure with glibc 2.34

* Jakub Jelinek: > On Mon, Jul 12, 2021 at 10:26:47AM +0200, Florian Weimer via Gcc-patches > wrote: >> is included indirectly in the #pragma GCC visibility hidden >> block. With glibc 2.34, needs a declaration of the sysconf >> function, and including it under hidde

Re: [PATCH] libgomp: Include early to avoid link failure with glibc 2.34

* Florian Weimer: > I tested this on csky-linux-gnuabiv2 with the glibc version that failed > before, and it works. So I guess your version is fine, too. Build on powerpc64-linux-gnu and other targets now fails with: /home/bmg/src/gcc/libgomp/config/linux/affinity.c: In function ‘gomp_init_affi

Re: [PATCH] libgomp: Include early to avoid link failure with glibc 2.34

* Florian Weimer: > * Florian Weimer: > >> I tested this on csky-linux-gnuabiv2 with the glibc version that failed >> before, and it works. So I guess your version is fine, too. > > Build on powerpc64-linux-gnu and other targets now fails with: > > /home/bmg/src/gcc/libgomp/config/linux/affinity.

Re: mention x86-64-vX micro-architecture levels in the release notes

* Matthias Klose: > Just saw, these are not mentioned on the release notes. Ok to document these? > > Matthias > > --- a/htdocs/gcc-11/changes.html > +++ b/htdocs/gcc-11/changes.html > @@ -690,6 +690,10 @@ You may also want to check out our >GCC now supports AMD CPUs based on the znver3 core >

Re: [RFC v2] bpf.2: Use standard types and attributes

* Alejandro Colomar: > The thing is, in all of those threads, the only reasons to avoid > types in the kernel (at least, the only explicitly > mentioned ones) are (a bit simplified, but this is the general idea of > those threads): > > * Possibly breaking something in such a big automated change.

Re: [PATCH 1/3] Compute a table of DWARF register sizes at compile

* Jeff Law: > On 11/8/22 11:05, Florian Weimer via Gcc-patches wrote: >> The sizes are compile-time constants. Create a vector with them, >> so that they can be inspected at compile time. >> >> * gcc/dwarf2cfi.cc (init_return_column_size): Remove. >>

[PATCH] Various fixes for DWARF register size computation

The previous code had several issues. 1. XALLOCAVEC does not create any objects, so invocating the non-POD poly_uint16 assignment operator is undefined. 2. The default constructor of poly-ints does not create a zero poly-int object (unlike what happens with regular ints). 3. The register siz

Re: [PATCH] Various fixes for DWARF register size computation

* Jakub Jelinek: > On Tue, Jan 03, 2023 at 12:15:23PM +0100, Florian Weimer wrote: >> --- a/gcc/debug.h >> +++ b/gcc/debug.h >> @@ -245,7 +245,18 @@ extern const struct gcc_debug_hooks vmsdbg_debug_hooks; >> >> /* Dwarf2 frame information. */ >> >> -extern int dwarf_reg_sizes_constant (); >>

[PATCH wwwdocs] Explicitly list powerpc64le-unknown-linux-gnu as a primary platform

The intent was that this was implied by powerpc64-unknown-linux-gnu, but this not very obvious because of the ELFv1 vs ELFv2 ABI differences. --- htdocs/gcc-10/criteria.html | 1 + htdocs/gcc-11/criteria.html | 1 + htdocs/gcc-9/criteria.html | 1 + 3 files changed, 3 insertions(+) diff --git a

Re: [PATCH] middle-end: Fold popcount(x&4) to (x>>2)&1 and friends.

* Richard Biener via Gcc-patches: > Given you know the constant bit position of the possibly nonzero > bit you can elide the conversion to unsigned for all but the case > of a possibly negative input (IIRC GCC doesn't yet take advantage > of negative right shift undefinedness - but maybe sanitizer

Re: [committed] libstdc++: Add std::from_chars for floating-point types

* Jonathan Wakely via Libstdc: > By replacing the use of strtod we could avoid allocation, avoid changing > locale, and use optimised code paths specific to each std::chars_format > case. We would also get more portable behaviour, rather than depending > on the presence of uselocale, and on any bu

Re: [PATCH wwwdocs] Explicitly list powerpc64le-unknown-linux-gnu as a primary platform

* Florian Weimer via Gcc-patches: > The intent was that this was implied by powerpc64-unknown-linux-gnu, > but this not very obvious because of the ELFv1 vs ELFv2 ABI > differences. > > --- > htdocs/gcc-10/criteria.html | 1 + > htdocs/gcc-11/criteria.html | 1 + > ht

Re: [committed] libstdc++: Add std::from_chars for floating-point types

* Jonathan Wakely: >>What seems to be missing is a function that takes an explicit buffer >>length. A static reference to the C locale object would be helpful as >>well, I assume. > > How expensive is it to do newlocale("C", nullptr), uselocale, and > freelocale? freelocale does nothing in this

Re: Should ARMv8-A generic tuning default to -moutline-atomics

* Joseph Myers: > I think this change is what introduced a glibc testsuite regression in the > localplt test. > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html > > Contents of elf/check-localplt.out: > > Extra PLT reference: libc.so: getauxval > > A reference to getauxval f

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

* Kyrylo Tkachov: > This patch fixes > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545004.html by using > __getauxval in the libgcc code. > Bootstrap and testing on aarch64-none-linux-gnu shows no problem. > From what I could gather from my glibc testing the elf/check-localplt test > pas

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

* Kyrylo Tkachov: > diff --git a/libgcc/config/aarch64/lse-init.c > b/libgcc/config/aarch64/lse-init.c > index 74acef25cce..57236610468 100644 > --- a/libgcc/config/aarch64/lse-init.c > +++ b/libgcc/config/aarch64/lse-init.c > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME respect

Re: [PATCH] Implement no_stack_protect attribute.

* Martin Liška: > The patch adds new no_stack_protect attribute. The change is requested > from kernel folks and is direct equivalent of Clang's no_stack_protector. > Unlike Clang, I chose to name it no_stack_protect because we already > have stack_protect attribute (used with -fstack-protector-ex

Re: [PATCH] Implement no_stack_protect attribute.

* Michael Matz: > Hello, > > On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote: > >> > The patch adds new no_stack_protect attribute. The change is requested >> > from kernel folks and is direct equivalent of Clang's no_stack_protector. &g

Re: [PATCH] Implement no_stack_protect attribute.

* Michael Matz: >> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at >> all for some reason, the frame pointer is always missing? > > Not for me: I see. I didn't know that -fno-omit-frame-pointer only applies to non-leaf functions. For them, the behavior I see matches yo

Re: [PATCH] doc: Clarify __builtin_return_address [PR94891]

* Szabolcs Nagy: > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index cced19d2018..0fd32a22599 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > On some machines it may be impossible to determine the return address of > any function other than the current one; in such

Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support

* Kwok Cheung Yeung: > From 788687f87ad41e51258738ce068ee38d7b24defc Mon Sep 17 00:00:00 2001 > From: Kwok Cheung Yeung > Date: Fri, 15 Jan 2021 04:49:36 -0800 > Subject: [PATCH] openmp: Add support for the OpenMP 5.0 task detach clause Sorry, this appears to cause OpenMP task state corruption i

Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support

* Jakub Jelinek: > Not all targets support GNU style function versioning where one can have > multiple symbol versions for the same symbol name, and I wanted to > avoid GOMP_task2, GOMP_task3 etc. Why? If it is about aesthetics, wouldn't compliance with language standards and ABI requirements be

  1   2   >