Re: [PATCH 3/7] **/*.texi: Reorder index entries

Hi! On 2023-01-27T01:18:31+0100, Arsen Arsenović via Gcc-patches wrote: > Much like the previous commit, this change is mostly mechanical I find it helpful to see in the Git commit log some kind of rationale, instead of just the almost-useless GNU ChangeLog snippets. ;-) > with a > simple scr

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

Hi Andrew, > >> Oh yeah, and in case you haven't figured it out on your own, you'll > >> have to remove WIDEN_MULT_EXPR from the range-ops init table.   This > >> non-standard mechanism only gets checked if there is no standard > >> range-op table entry for the tree code :-P > >> > > Hmm it looks

[PATCH 8/8] libstdc++: Test that integral simd reductions are precise

Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: * testsuite/experimental/simd/tests/reductions.cc: Introduce max_distance as the type-dependent max error. --- libstdc++-v3/testsuite/experimental/simd/tests/reductions.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletio

[PATCH 4/8] libstdc++: Add missing constexpr on simd shift implementation

Resolves -Wtautological-compare warnings about `if (__builtin_is_constant_evaluated())` in the implementations of these functions. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: * include/experimental/bits/simd_x86.h (_S_bit_shift_left) (_S_bit_shift_right): Declare con

[PATCH 6/8] libstdc++: Fix formatting

Whitespace changes only. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: * include/experimental/bits/simd.h: Line breaks and indenting fixed to follow the libstdc++ standard. * include/experimental/bits/simd_builtin.h: Likewise. * include/experimental/bit

Re: [PATCH 3/7] **/*.texi: Reorder index entries

Hi Thomas, Thomas Schwinge writes: > Hi! > > On 2023-01-27T01:18:31+0100, Arsen Arsenović via Gcc-patches > wrote: >> Much like the previous commit, this change is mostly mechanical > > I find it helpful to see in the Git commit log some kind of rationale, > instead of just the almost-useless

[PATCH 7/8] libstdc++: Fix -Wsign-compare issue

Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: * include/experimental/bits/simd_builtin.h (_S_set): Compare as int. The actual range of these indexes is very small. --- libstdc++-v3/include/experimental/bits/simd_builtin.h | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PATCH 2/8] libstdc++: Fix simd build failure on clang

Clang does not support __attribute__ on lambdas. Therefore, only set _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA if __clang__ is not defined. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108030 * include/experimental/bits/simd_detail.h (_GLIBCXX_SIMD_ALWAY

[PATCH 5/8] libstdc++: Always-inline most of non-cmath fixed_size implementation

For simd, the inlining behavior should be similar to builtin types. (No operator on buitin types is ever translated into a function call.) Therefore, always_inline is the right choice (i.e. inline on -O0 as well). Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/1080

[PATCH 3/8] libstdc++: More efficient masked inc-/decrement implementation

Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108856 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_masked_unary): More efficient implementation of masked inc-/decrement for integers and floats without AVX2.

[PATCH 1/8] libstdc++: Simplify three helper functions into one

Broadcast is a very common function. This should reduce compile-time effort. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108030 * include/experimental/bits/simd.h (__vector_broadcast): Implement via __vector_broadcast_impl instead of __ca

[PATCH 0/8] std::experimental::simd patchset

Tested on x86_64-pc-linux. This patchset provides the final changes for PR108030 and resolves PR108856. The latter is a pure optimization and could wait for Stage 1 (I'm submitting the patch because simd is experimental/TS) Matthias Kretz (8): libstdc++: Simplify three helper functions into o

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On Wed, Feb 22, 2023 at 5:42 PM Michael Collison wrote: > > Richard how would I check for a full masked main vector loop? It's LOOP_VINFO_FULLY_MASKED_P I think. For the odd prologue peeling you see you might want to check why vect_use_loop_mask_for_alignment_p isn't true (possibly because exact

[PATCH v2] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

The PCH mechanism first tries to map the .gch file to the virtual memory space pointed to by TRY_EMPTY_VM_SPACE during the compilation process. The original value of TRY_EMPTY_VM_SPACE macro is 0x80, but like la464 only has 40 bits of virtual address space, this value just exceeds the addr

Re: [PATCH 2/2] xtensa: Fix missing mode warnings in machine description

On Wed, Feb 22, 2023 at 7:42 PM Takayuki 'January June' Suwa wrote: > > gcc/ChangeLog: > > * config/xtensa/xtensa.md > (zero_cost_loop_start, zero_cost_loop_end, loop_end): > Add missing "SI:" to PLUS RTXes. > --- > gcc/config/xtensa/xtensa.md | 12 ++-- > 1 file c

Re: [PATCH 1/2] xtensa: Fix non-fatal regression introduced by b2ef02e8cbbaf95fee98be255f697f47193960ec

On Wed, Feb 22, 2023 at 7:42 PM Takayuki 'January June' Suwa wrote: > > In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call > insn included (use (reg:SI A0_REG)) to fix the problem, which added > a USE chain unconditionally to the data flow of register A0 during > the sibling call

[COMMITTED 2/2] xtensa: fix PR target/108876

In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call insn included (use (reg:SI A0_REG)) to fix the problem, which added a USE chain unconditionally to the data flow of register A0 during the sibling call. As a result, df_regs_ever_live_p (A0_REG) returns true, so even if register

[COMMITTED 1/2] Revert "gcc: xtensa: fix PR target/108876"

This reverts commit b2ef02e8cbbaf95fee98be255f697f47193960ec. --- gcc/config/xtensa/xtensa.cc | 2 ++ gcc/config/xtensa/xtensa.md | 20 +++- 2 files changed, 9 insertions(+), 13 deletions(-) diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc index 5c1c713e122d

Re: (rebased patchset) [PATCH 3/7] **/*.texi: Reorder index entries

Hi Gerald, Thanks for the review. Gerald Pfeifer writes: > I was going to push this, alas there are now rejects for > fortran/invoke.texi, gcc/doc/invoke.texi and gcc/doc/cppopts.texi. > > If you can get me a rebased version I'll give it a try again. (Or > are there some earlier dependencies? I

Re: [PATCH 3/3] vect: inbranch SIMD clones

On 10/02/2023 09:11, Jakub Jelinek wrote: I've tried to fix the -flto thing and I can't figure out how. The problem seems to be that there are two dump files from the two compiler invocations and it scans the wrong one. Aarch64 has the same problem. Two dumps are because it is in a dg-do run te

[PATCH] tree-optimization/108888 - call if-conversion

The following makes sure to only predicate calls necessary. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/10 * tree-if-conv.cc (if_convertible_stmt_p): Set PLF_2 on calls to predicate. (predicate_statements): Only predicate c

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On 22/02/2023 19:57, Alexandre Oliva wrote: On Feb 21, 2023, Richard Earnshaw wrote: Rather than scanning for the triplet, a better test would be { xfail { arm_eabi } } Indeed, thanks. Here's the updated patch, retested. Ok to install? Based on Nathan's comments, we should just ski

[PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

Hi! _Float16 and decltype(0.0bf16) types are on x86 supported only with -msse2. On x86_64 that is the default, but on ia32 it is not. We should still emit fundamental type tinfo for those types in libsupc++.a/libstdc++.*, regardless of whether libsupc++/libstdc++ is compiled with -msse2 or not, a

[PATCH] c++: Fix up -fcontracts option description [PR108890]

Hi! This translation PR mentioned the description is a little bit weird. Ok for trunk? 2023-02-23 Jakub Jelinek PR translation/108890 * c.opt (fcontracts): Fix description. --- gcc/c-family/c.opt.jj 2023-02-01 10:19:42.637146215 +0100 +++ gcc/c-family/c.opt 2023-02-23

[PATCH v2 0/5] A small Texinfo refinement

Morning, (as said in ) This is a rebase + slight amendment of the previous patch series visible at: https://inbox.sourceware.org/gcc-patches/cover.1674777149.git.ar...@aarsen.me/ The commit "docs: Reorder @opindex to be before

[PATCH v2 1/5] docs: Create Indices appendix

The GCC manual has multiple indices. By creating an appendix which lists them, we help makeinfo present a more accessible way for the reader to see all the indices. gcc/ChangeLog: * doc/gcc.texi: Add the Indices appendix, to make texinfo generate nice indices overview page.

[PATCH v2 5/5] update_web_docs_git: Update CSS reference to new manual CSS

maintainer-scripts/ChangeLog: * update_web_docs_git (CSS): Update CSS reference to point to /texinfo-manuals.css. --- maintainer-scripts/update_web_docs_git | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/maintainer-scripts/update_web_docs_git b/maintainer-scr

[PATCH v2 3/5] doc: Add @defbuiltin family of helpers, set documentlanguage

The @defbuiltin{,x} macros are convenience macros for the often-repeated task of defining a built-in function in extend.texi. Usage of this macro should lead to a higher degree of consistency across pieces of text written by different people, and provide a better reading experience, as they preven

Re: [PATCH] ipa-prop: Fix another case of missing BUILT_IN_UNREACHABLE_TRAP handling [PR106258]

On Thu, Feb 23, 2023 at 7:56 AM Jakub Jelinek wrote: > > On Wed, Feb 22, 2023 at 07:46:46PM +0100, Richard Biener wrote: > > Ok for stage1 > > Thanks. In that case, can we get at least following into GCC 13, > another spot that handles in IPA just BUILT_IN_UNREACHABLE and > not BUILT_IN_UNREACHAB

[PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]

Hi! The translation PR complains that these 4 messages from xtensa-dynconfig.c are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they should be gcc-internal-format. The problem is in the manual translation of the strings with _(), that should be both unnecessary because fatal_e

Re: [PATCH] libgcc_s: Use alias for __cpu_indicator_init instead of symver

On Wed, Feb 22, 2023 at 04:23:33AM -0800, Yash Shinde wrote: > From: Khem Raj > > Adapter from > > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00899.html > > This fix was debated but hasnt been applied gcc upstream since > they expect musl to support '@' in symbol versioning which is > a sun/

Re: [committed 034/103] gccrs: dump: Emit visibility when dumping items

On 2/23/23 02:01, Gerald Pfeifer wrote: Just noticed this by chance: How does this patch constitute a functional change (that matches the ChangeLog)? It looks it only adds an empty line to the source code? Huh. That is weird. Sorry about that! This range of commits on our AST dump contained

[PATCH] Fix memory leak in if-conversion

The following fixes if-conversion failing to release data-references and the data-reference vector. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. * tree-if-conv.cc (tree_if_conversion): Properly manage memory of refs and the contained data references. --- gcc/tre

Re: [PATCH 1/8] libstdc++: Simplify three helper functions into one

On Thu, 23 Feb 2023 at 08:53, Matthias Kretz via Libstdc++ wrote: > > > > Broadcast is a very common function. This should reduce compile-time > effort. OK for all branches. > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > PR libstdc++/108030 > * include/experimen

Re: [PATCH 2/8] libstdc++: Fix simd build failure on clang

On Thu, 23 Feb 2023 at 08:54, Matthias Kretz via Libstdc++ wrote: > > > > Clang does not support __attribute__ on lambdas. Therefore, only set > _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA if __clang__ is not defined. OK for all branches. > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > >

Re: [PATCH 4/8] libstdc++: Add missing constexpr on simd shift implementation

On Thu, 23 Feb 2023 at 08:55, Matthias Kretz via Libstdc++ wrote: > > > > Resolves -Wtautological-compare warnings about `if > (__builtin_is_constant_evaluated())` in the implementations of these > functions. The 'inline' is redundant now, because these are unconditionally constexpr which implies

Re: [PATCH 7/8] libstdc++: Fix -Wsign-compare issue

On Thu, 23 Feb 2023 at 08:51, Matthias Kretz via Libstdc++ wrote: > > OK for all branches. > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > * include/experimental/bits/simd_builtin.h (_S_set): Compare as > int. The actual range of these indexes is very small. > --

Re: [PATCH 8/8] libstdc++: Test that integral simd reductions are precise

On Thu, 23 Feb 2023 at 08:51, Matthias Kretz via Libstdc++ wrote: > OK for all branches. > > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > * testsuite/experimental/simd/tests/reductions.cc: Introduce > max_distance as the type-dependent max error. > --- > libstd

Re: [PATCH 4/8] libstdc++: Add missing constexpr on simd shift implementation

On Thursday, 23 February 2023 12:07:11 CET Jonathan Wakely wrote: > On Thu, 23 Feb 2023 at 08:55, Matthias Kretz via Libstdc++ > > wrote: > > Resolves -Wtautological-compare warnings about `if > > (__builtin_is_constant_evaluated())` in the implementations of these > > functions. > > The 'inline

[gcc] RTEMS: Tune multilib selection

gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. --- gcc/config/riscv/t-rtems | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/gcc/config/riscv/t-rtems b/gcc/config/riscv/t-rte

[PATCH][wwwdocs][committed] Extend changes.html entries for arm and aarch64

Hi all, Here's a patch that fleshes out the changes.html entries for arm and aarch64. I did a quick scan through appropriately filtered git logs and wrote up stuff that I think is user-visible, but please shout if you know of things that should be highlighted as there's been much great work done

[committed][OG12] libgomp: no need to attach USM pointers

This patch fixes a bug in which libgomp doesn't know what to do with attached pointers in fortran derived types when using Unified Shared Memory instead of explicit mappings. I've committed it to the devel/omp/gcc-12 branch (OG12) and will fold it into the next rebase/repost of the USM patches

[PATCH] Avoid default-initializing auto_vec storage

The following avoids default-initializing auto_vec storage for non-POD T since that's not what the allocated storage fallback will do and it's also not expected for existing cases like auto_vec, 64> elts; which exist to optimize the allocation. Bootstrapped and tested on x86_64-unknown-linux-g

[PATCH] Fix memory leak in PTA

When handle_lhs_call calls .create on the passed in vector it leaks any previous allocated storage. Avoid doing that and instead rely on the caller for memory management, just truncate the vector. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-ssa-structalias.cc (handl

Re: [PATCH] Avoid default-initializing auto_vec storage

On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote: > The following avoids default-initializing auto_vec storage for > non-POD T since that's not what the allocated storage fallback > will do and it's also not expected for existing cases like > > auto_vec, 64> elts; > > which exist

Fwd: [v3][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

Ping * 2. Hi, Joseph and Richard, Could you please review this patch and let me know whether it’s ready for committing into GCC13? This is an important bug that need to be fixed for kernel security purpose. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>>

Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

Ping * 2. Hi, Joseph and Richard, Could you please review this patch and let me know whether it’s ready for committing into GCC13? thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR7

Re: [PATCH] c++: Fix up -fcontracts option description [PR108890]

On Thu, Feb 23, 2023 at 11:26:27AM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > This translation PR mentioned the description is a little bit weird. > > Ok for trunk? I think this is OK... > 2023-02-23 Jakub Jelinek > > PR translation/108890 > * c.opt (fcontracts): Fix

[PATCH] testsuite: Fix up modules.exp [PR108899]

Hi! On Wed, Feb 22, 2023 at 02:33:42PM -0300, Alexandre Oliva via Gcc-patches wrote: > When a multi-source module is found to be unsupported, we fail > module_cmi_p and subsequent sources. Override proc unsupported to > mark the result in module_do, and test it to skip module_cmp_p and > subseque

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

On 23.02.23 00:29, Gerald Pfeifer wrote: On Wed, 22 Feb 2023, Tobias Burnus wrote: Comments? Suggestions? Would it make sense to sort AMD GCN and nvptx alphabetically (and in turn switch the order)? From a wwwdocs perspective the changes look fine. Thanks for having a look. I swapped them a

Re: [PATCH] Avoid default-initializing auto_vec storage

On Thu, 23 Feb 2023, Jakub Jelinek wrote: > On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote: > > The following avoids default-initializing auto_vec storage for > > non-POD T since that's not what the allocated storage fallback > > will do and it's also not expected for existing case

Re: [PATCH] testsuite: Fix up modules.exp [PR108899]

On Thu, 23 Feb 2023, Jakub Jelinek wrote: > Hi! > > On Wed, Feb 22, 2023 at 02:33:42PM -0300, Alexandre Oliva via Gcc-patches > wrote: > > When a multi-source module is found to be unsupported, we fail > > module_cmi_p and subsequent sources. Override proc unsupported to > > mark the result in

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

Hi, and welcome to the GCC / gfortran community. On 23.02.23 14:15, varma datla via Fortran wrote: I am willing to contribute to the project idea "Fortran – DO CONCURRENT". I hope the following helps a bit – it is admittedly a bit chaotic, but I try to write something cleaner later. But to h

[PATCH] libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP - without it, it effectively has Load-AcquirePC semantics similar to LDAPR, which is less restrictive than what __ATOMIC_SEQ_CST requires. This patch fixes this and adds comments to make it easier to see which sequence is us

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Wed, 22 Feb 2023, Marek Polacek wrote: > In this test, we get a bogus error because we failed to deduce the auto in > constexpr auto is_pointer_v = is_pointer::value; > to bool. Then ensure_literal_type_for_constexpr_object thinks the object > isn't literal and an error is reported. > > This

Re: [PATCH] Avoid default-initializing auto_vec storage

On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote: > > > * vec.h (auto_vec): Turn m_data storage into > > > uninitialized unsigned char. > > > > Given that we actually never reference the m_data array anywhere, > > it is just to reserve space, I think even the alignas(T) there is

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

I wonder if a relatively easy starting point would be enabling the declaration of do concurrent construct variables: do concurrent (integer :: i = 1:n) It’s a minor convenience and less exciting than adding locality specifiers but possibly a good first exercise. Damian On Thu, Feb 23, 2023 at

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: > On Wed, 22 Feb 2023, Marek Polacek wrote: > > > In this test, we get a bogus error because we failed to deduce the auto in > > constexpr auto is_pointer_v = is_pointer::value; > > to bool. Then ensure_literal_type_for_constexpr_obje

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote: > I wonder if a relatively easy starting point would be enabling the > declaration of do concurrent construct variables: > > do concurrent (integer :: i = 1:n) > > It’s a minor convenience and less exciting than adding locality specif

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

On 2/23/23 03:36, Tamar Christina wrote: Hi Andrew, Oh yeah, and in case you haven't figured it out on your own, you'll have to remove WIDEN_MULT_EXPR from the range-ops init table.   This non-standard mechanism only gets checked if there is no standard range-op table entry for the tree code :

Re: [Patch] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

Minor change to previous patch – it did not affect the mainline build but it makes more sense this way and on OG12, i.e. with mapping allocatable components (patch posted last year in Q1 during Stage 4), it gave an ICE without this change as one '*' wasn't stripped. --- b/gcc/fortran/trans-openmp

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

> -Original Message- > From: Andrew MacLeod > Sent: Thursday, February 23, 2023 4:40 PM > To: Tamar Christina ; Richard Biener > ; Richard Sandiford > Cc: Tamar Christina via Gcc-patches ; nd > ; j...@ventanamicro.com > Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bit

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On Feb 23, 2023, Richard Earnshaw wrote: > On 22/02/2023 19:57, Alexandre Oliva wrote: >> On Feb 21, 2023, Richard Earnshaw wrote: >> >>> Rather than scanning for the triplet, a better test would be >> >>> { xfail { arm_eabi } } >> >> Indeed, thanks. Here's the updated patch, retested. Ok t

[PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite

Reviews of the resize_and_overwite description welcome. I've tried to strike a balance between pedantic precision and user-friendliness. -- >8 -- This is a complicated API that should be clearly documented. Also improve the comment on basic_ios::_M_setstate. libstdc++-v3/ChangeLog: * i

Re: [PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite

Am Do., 23. Feb. 2023 um 18:38 Uhr schrieb Jonathan Wakely via Libstdc++ : > > Reviews of the resize_and_overwite description welcome. I've tried to > strike a balance between pedantic precision and user-friendliness. > > -- >8 -- > > This is a complicated API that should be clearly documented. > >

Re: [PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite

On Thu, 23 Feb 2023 at 17:42, Daniel Krügler wrote: > > Am Do., 23. Feb. 2023 um 18:38 Uhr schrieb Jonathan Wakely via > Libstdc++ : > > > > Reviews of the resize_and_overwite description welcome. I've tried to > > strike a balance between pedantic precision and user-friendliness. > > > > -- >8 --

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

On Feb 22, 2023, Alexandre Oliva wrote: >> Just curious, why doesn't the pmf hack work on arm-vxworks7? > At first, I thought we were running into this just because we have to > define __clang__ because of some vxworks system headers aimed at clang. > But even as I tried to drop the #ifndef, the

Re: Ping^2: [PATCH+wwwdocs 0/8] A small Texinfo refinement

On 2/22/23 18:26, Gerald Pfeifer wrote: On Tue, 21 Feb 2023, Arsen Arsenović wrote: Ping. Like last time, I rebased the series. Thank you! The first two times around, I did not notice there's dedicated maintainers for the documentation component, and so, I am adding Gerald, Joseph and Sandr

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

On Thu, 23 Feb 2023 at 17:55, Alexandre Oliva wrote: > > On Feb 22, 2023, Alexandre Oliva wrote: > > >> Just curious, why doesn't the pmf hack work on arm-vxworks7? > > > At first, I thought we were running into this just because we have to > > define __clang__ because of some vxworks system head

Re: [gcc] RTEMS: Tune multilib selection

On Thu, 23 Feb 2023 03:48:26 PST (-0800), sebastian.hu...@embedded-brains.de wrote: gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. --- gcc/config/riscv/t-rtems | 17 + 1 file changed, 9 insert

[PATCH] Fix std::unordered_map key range insertion

Hi Based on my work on PR 96088 for std::map I imagine this use case of inserting a range of keys into an associative container. It behaves as operator[] by inserting a default value for each key. I wonder if the Standard says that it should work. Or maybe we want to support it ? I haven't

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On Feb 23, 2023, Alexandre Oliva wrote: > On Feb 23, 2023, Richard Earnshaw wrote: >> On 22/02/2023 19:57, Alexandre Oliva wrote: >>> On Feb 21, 2023, Richard Earnshaw wrote: >>> Rather than scanning for the triplet, a better test would be >>> { xfail { arm_eabi } } >>> >>> Indeed,

Re: [PATCH v2] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On Fri, Dec 9, 2022 at 10:25 AM Raphael Moreira Zinsly wrote: > > Changes since v1: > - Fixed formatting issues. > - Added a name to the define_insn_and_split pattern. > - Set the target on the 'dg-do compile' in pr106602.c. > - Removed the rv32 restriction in pr956

Re: Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > +@item > +The structure with a C99 flexible array member is the field of > +another union, for example: > + > +@smallexample > +struct flex1 @{ int length1; char data1[]; @} > +struct flex2 @{ int length2; char data2[]; @} > + > +union out_

[PATCH] c++: non-dependent variable template-id [PR108848]

Here we're incorrectly treating the non-dependent variable template-id tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR an empty type which causes the call to finish_template_variable from finish_id_expression_1 to be dead code at template parse time. Thus we're led into treating

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> On Feb 23, 2023, at 4:24 PM, Joseph Myers wrote: > > On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > >> +@item >> +The structure with a C99 flexible array member is the field of >> +another union, for example: >> + >> +@smallexample >> +struct flex1 @{ int length1; char data1[]; @}

Re: [PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]

Hi Jakub, On Thu, Feb 23, 2023 at 2:34 AM Jakub Jelinek wrote: > The translation PR complains that these 4 messages from xtensa-dynconfig.c > are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they > should be gcc-internal-format. > > The problem is in the manual translation of

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> On Feb 23, 2023, at 5:04 PM, Qing Zhao via Gcc-patches > wrote: > > > >> On Feb 23, 2023, at 4:24 PM, Joseph Myers wrote: >> >> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: >> >>> +@item >>> +The structure with a C99 flexible array member is the field of >>> +another union, for

Re: [PATCH v5] xtensa: Eliminate unnecessary general-purpose reg-reg moves

On Fri, Feb 17, 2023 at 8:43 PM Takayuki 'January June' Suwa wrote: > > Register-register move instructions that can be easily seen as > unnecessary by the human eye may remain in the compiled result. > For example: > > /* example */ > double test(double a, double b) { > return __builtin_copysig

Re: [PATCH v7] xtensa: Eliminate the use of callee-saved register that saves and restores only once

On Thu, Feb 16, 2023 at 11:54 PM Takayuki 'January June' Suwa wrote: > > In the case of the CALL0 ABI, values that must be retained before and > after function calls are placed in the callee-saved registers (A12 > through A15) and referenced later. However, it is often the case that > the save an

Re: [PATCH 1/2] xtensa: Fix non-fatal regression introduced by b2ef02e8cbbaf95fee98be255f697f47193960ec

On Thu, Feb 23, 2023 at 1:35 AM Max Filippov wrote: > > On Wed, Feb 22, 2023 at 7:42 PM Takayuki 'January June' Suwa > wrote: > > > > In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call > > insn included (use (reg:SI A0_REG)) to fix the problem, which added > > a USE chain uncond

Re: [PATCH v2 2/5] **/*.texi: Reorder index entries

On Thu, 23 Feb 2023, Arsen Arsenović wrote: > This change is a generalization of r13-6292-gddf6fe375d9110. : > gcc/d/ChangeLog: > > * implement-d.texi: Reorder index entries around @items. > > gcc/ChangeLog: > > * doc/cfg.texi: Reorder index entries around @items. > * doc/cpp.t

[PATCH] c++: ICE with constexpr variable template [PR107938]

Since r11-557, cp_finish_decl can call check_initializer even in a template for a constexpr initializer. That ultimately leads to convert_for_assignment and check_address_or_pointer_of_packed_member, where we crash, because it doesn't expect that the CALL_EXPR is a function object. Q has a conste

[COMMITTED 2/2] gcc: xtensa: update include style in xtensa-dynconfig.cc

gcc/ * config/xtensa/xtensa-dynconfig.cc (config.h, system.h) (coretypes.h, diagnostic.h, intl.h): Use "..." instead of <...> for the gcc-internal headers. --- gcc/config/xtensa/xtensa-dynconfig.cc | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[COMMITTED 1/2] gcc: xtensa: rename xtensa-dynconfig.c and update its build rule

gcc/ * config/xtensa/t-xtensa (xtensa-dynconfig.o): Use $(COMPILE) and $(POSTCOMPILE) instead of manual dependency listing. * config/xtensa/xtensa-dynconfig.c: Rename to ... * config/xtensa/xtensa-dynconfig.cc: ... this. --- gcc/config/xtensa/t-xtensa

Re: [wwwdocs] Add revised Texinfo manual CSS

On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote: > htdocs/texinfo-manuals.css | 129 + Thank you - I pushed this. +/* Texinfo documentation stylesheet. + Inspired by the Gnulib manual, 2023-01-26. + + Arsen Arsenović Can we rephrase this a bit?

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > But the following: > > struct flex1 { int length1; char data1[]; }; > struct flex2 { int length2; char data2[]; }; > union union_flex { struct flex1 f1; struct flex2 f2; }; /* this is C > standard. */ > > struct out_flex { int n; union

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

On Thu, 23 Feb 2023, Tobias Burnus wrote: > PS: I also removed a stray , but admittedly only after the > commit. I found it by manually running those through the w3 validator > site. However, I did not see an automatic email, either it takes longer > or does it no longer run? It did in the past! Y

[PATCH] RISC-V: Disable attribute generation by default

We generate a handful of attributes by default, but they don't really encode any useful information. We've broadly stopped ascribing any meaning to them in binutils; but they trip up LLVM, older toolchains, and users. So let's just turn them off by default. The old binaries will still be floatin

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On 2/22/23 21:50, Michael Collison wrote: Hi Jeff, We do not have two independent implementations: my work is 100% based on the vector intrinsic foundation in upstream GCC. Phew! That's good news. I totally misunderstood. In fact I have only added two core patterns, vector add and sub

Re: [PATCH] vect: Check that vector factor is a compile-time constant

Hi Jeff: > What I'd been planning to do internally at Ventana was to update our > codebase to gcc-13 once it's released. Then I'd backport RVV autovec > work from the gcc-14 dev tree into that Ventana branch. > > Instead, but along the same lines, we could have a public gcc-13 based > branch whic

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi, It's been a while since this patch is sent. This patch is very important for us since we are going to release RVV intrinsic support in GCC 13. And this is the patch to fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108654 Can any one verifies this patch for us? Thanks. juzhe.zh...

Re: Support for WEAK attribute, part 2

On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf wrote: > the patch is mostly fine, but there is a minor style issue: > > + if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK)) > + gfc_error ("Symbol %qs at %L has the WEAK attribute but is a %s", > + sym->name, &sym->declared_a

[PATCH v3 00/11] RISC-V: Add XThead* extension support

From: Christoph Müllner This series introduces support for the T-Head specific RISC-V ISA extensions which are available e.g. on the T-Head XuanTie C906. The ISA spec can be found here: https://github.com/T-head-Semi/thead-extension-spec This series adds support for the following XThead* exte

[PATCH v3 02/11] riscv: riscv-cores.def: Add T-Head XuanTie C906

From: Christoph Müllner This adds T-Head's XuanTie C906 to the list of known cores as "thead-c906". The C906 is shipped for quite some time (it is the core of the Allwinner D1). Note, that the tuning struct for the C906 is already part of GCC (it is also name "thead-c906"). gcc/ChangeLog:

[PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

From: Christoph Müllner This patch adds support for the XTheadBs ISA extension. The new INSN pattern is defined in a new file to separate this vendor extension from the standard extensions. The cost model adjustment reuses the xbs:bext cost. gcc/ChangeLog: * config/riscv/riscv.cc (riscv

[PATCH v3 01/11] riscv: Add basic XThead* vendor extension support

From: Christoph Müllner This patch add basic support for the following XThead* ISA extensions: * XTheadBa * XTheadBb * XTheadBs * XTheadCmo * XTheadCondMov * XTheadFMemIdx * XTheadFmv * XTheadInt * XTheadMac * XTheadMemIdx * XTheadMemPair * XTheadSync The extensions are just recognized by the c

[PATCH v3 07/11] riscv: thead: Add support for the XTheadMac ISA extension

From: Christoph Müllner The XTheadMac ISA extension provides multiply-accumulate/subtract instructions: * mula/mulaw/mulah * muls/mulsw/mulsh To benefit from middle-end passes, we expand the following named patterns in riscv.md (as they are not T-Head-specific): * maddhisi4 * msubhisi4 gcc/Chan

[PATCH v3 05/11] riscv: thead: Add support for the XTheadBb ISA extension

From: Christoph Müllner This patch adds support for the XTheadBb ISA extension. Thus, there is a functional overlap of the new instructions with existing Bitmanip instruction, which allows a good amount of code sharing. However, the vendor extensions are cleanly separated from the standard extens

[PATCH v3 06/11] riscv: thead: Add support for the XTheadCondMov ISA extensions

From: Christoph Müllner This patch adds support for XTheadCondMov ISA extension. The extension brings a one-sided conditional move (no else-assignment). Given that GCC has a great if-conversion pass, we don't need to do much, besides properly expanding movcc accordingly and adjust the cost model.

  1   2   >