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

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: 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

[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/

[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

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

[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

[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] 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] 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] 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] 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] 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

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] 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: [libstdc++] use strtold for from_chars even without locale

* Jonathan Wakely via Libstdc: > We could use strtod for a single-threaded target (i.e. > !defined(_GLIBCXX_HAS_GTHREADS) by changing the global locale using > setlocale, instead of changing the per-thread locale using uselocale. This is not generally safe because the call to setlocale is still o

[PATCH] libstdc++: Mention recent libgcc_s symbol versions in manual

GCC_11.0 is an aarch64-specific outlier. * doc/xml/manual/abi.xml (abi.versioning.history): Add GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for libgcc_s. --- libstdc++-v3/doc/xml/manual/abi.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/libstdc++-

Re: libsanitizer: sync from master

* Martin Liška: > On 4/26/23 20:31, Florian Weimer wrote: >> * Martin Liška: >> >>> On 11/15/22 16:47, Martin Liška wrote: Hi. I've just pushed libsanitizer update that was tested on x86_64-linux and ppc64le-linux systems. Moreover, I run bootstrap on x86_64-linux and ch

Re: libsanitizer: sync from master

* Martin Liška: > On 11/15/22 16:47, Martin Liška wrote: >> Hi. >> >> I've just pushed libsanitizer update that was tested on x86_64-linux and >> ppc64le-linux systems. >> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with >> abidiff. > > Hello. > > And I've done the same

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] 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 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. >>

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

* Marek Polacek via Gcc-patches: > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 726392409b6..2de14466dd3 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -16510,6 +16510,14 @@ The option cannot be combined with > @option{-fsanitize=thread} or > @option{-fsani

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

* Jakub Jelinek: > On Thu, Nov 24, 2022 at 11:01:40AM +0100, Florian Weimer via Gcc-patches > wrote: >> * Joseph Myers: >> >> > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote: >> > >> >> Without this change, finish_declspecs cannot tel

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

* Joseph Myers: > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote: > >> Without this change, finish_declspecs cannot tell that whether there >> was an erroneous type specified, or no type at all. This may result >> in additional diagnostics for implicit ints

[PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

Without this change, finish_declspecs cannot tell that whether there was an erroneous type specified, or no type at all. This may result in additional diagnostics for implicit ints, or missing diagnostics for multiple types. PR c/107805 gcc/c/ * c-decl.cc (declspecs_add_type): Pr

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

* Thomas Neumann: > Hi, > > When dynamically linking a fast enough machine hides the latency, but when > Statically linking or on slower devices this change caused a 5x increase > in > Instruction count and 2x increase in cycle count before getting to main. > > I have looked at wa

[PATCH 2/3] Define __LIBGCC_DWARF_REG_SIZES_CONSTANT__ if DWARF register size is constant

And use that to speed up the libgcc unwinder. * gcc/debug.h (dwarf_reg_sizes_constant): Declare. * gcc/dwarf2cfi.cc (dwarf_reg_sizes_constant): New function. * gcc/c-family/c-cppbuiltin.c (__LIBGCC_DWARF_REG_SIZES_CONSTANT__): Define if constant is known. l

[PATCH 3/3] libgcc: Specialize execute_cfa_program in DWARF unwinder for alignments

The parameters fs->data_align and fs->code_align always have fixed values for a particular target in GCC-generated code. Specialize execute_cfa_program for these values, to avoid multiplications. gcc/ * c-family/c-cppbuiltin.c (c_cpp_builtins): Define __LIBGCC_DWARF_CIE_DATA_ALIG

[PATCH 0/3] Further libgcc unwinder improvements

This series makes some further unwinder improvements. Unfortunately, not many targets define __LIBGCC_DWARF_REG_SIZES_CONSTANT__; x86-64 does, and it makes uw_install_context_1 quite a bit faster because GCC no longer has to emit generic memcpy code for it. In general, it may be worthwhile to rep

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

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. (init_one_dwarf_reg_size): Adjust. (generate_dwarf_reg_sizes): New function. Extracted from expand

Re: [PATCH 2/2] libstdc++: Move stream initialization into compiled library [PR44952]

* Patrick Palka: > On Fri, 4 Nov 2022, Florian Weimer wrote: > >> * Patrick Palka via Gcc-patches: >> >> > This patch moves the global object for constructing the standard streams >> > out from and into the compiled library on targets that support >> > the init_priority attribute. This means th

Re: [PATCH 2/2] libstdc++: Move stream initialization into compiled library [PR44952]

* Patrick Palka via Gcc-patches: > This patch moves the global object for constructing the standard streams > out from and into the compiled library on targets that support > the init_priority attribute. This means that no longer > introduces a separate global constructor in each TU that includ

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

* Jakub Jelinek: >> +#undef C >> + >> + /* Validate the augmentation length, and return the enconding after >> + it. No check for the return address column because it is >> + byte-encoded with CIE version 1. */ >> + if (__builtin_expect ((value & mask) == expected >> +

[PATCH v2] 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: 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] 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

[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 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] 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

[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

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] 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):

[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: 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

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] 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 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] Add optional __Bfloat16 support

* liuhongt via Libc-alpha: > +\subsubsection{Special Types} > + > +The \code{__Bfloat16} type uses a 8-bit exponent and 7-bit mantissa. > +It is used for \code{BF16} related intrinsics, it cannot be > +used with standard C operators. I think it's not necessary to specify whether the type supports

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

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] 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: [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: >> >> > 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: > 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 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] 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 >

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

[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] elf: Add __libc_get_static_tls_bounds [BZ #16291]

* Fāng-ruì Sòng: >> I *think* you can get what you need via existing GLIBC_PRIVATE >> interfaces. But in order to describe how to caox the data out of glibc, >> I need to know what you need. > > Unfortunate no, not reliably. Currently _dl_get_tls_static_info > (https://github.com/llvm/llvm-projec

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

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

[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: [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

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: [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 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 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,

[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 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; >

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/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 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

* 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/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 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

[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: 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

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

[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

[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 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 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 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 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 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 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 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

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: [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

* 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: > 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

[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][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

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: 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: [PATCH, V2] Add conversions between _Float128 and Decimal.

* Michael Meissner via Gcc-patches: > On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote: >> This change appears to have broken builds for powerpc in a configuration >> that bootstraps a cross toolchain starting with a GCC build with no libc >> available. >> >> Specifically, such a bo

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] 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] 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

  1   2   >