Re: [PATCH] i386[stv]: Handle REG_EH_REGION note

On Thu, Mar 14, 2024 at 3:22 PM Uros Bizjak wrote: > > On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote: > > > > When we split > > (insn 37 36 38 10 (set (reg:DI 104 [ _18 ]) > > (mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct > > SQRefCounted

[PATCH v2 04/12] extend.texi: Add documentation for __is_function

gcc/ChangeLog: * doc/extend.texi (__is_function): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index ae06e4da022..a94ad7955fe 100644 --- a/gcc/doc/extend.texi +++

Re: [PATCH] i386[stv]: Handle REG_EH_REGION note

On Thu, Mar 14, 2024 at 8:32 AM Hongtao Liu wrote: > > On Thu, Mar 14, 2024 at 3:22 PM Uros Bizjak wrote: > > > > On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote: > > > > > > When we split > > > (insn 37 36 38 10 (set (reg:DI 104 [ _18 ]) > > > (mem:DI (reg/f:SI 98 [

Re: [PATCH] contrib/gcc-changelog/git_check_commit.py: Implement --num-commits

On Fri, Mar 8, 2024 at 8:42 AM Patrick Palka wrote: > > On Wed, 28 Feb 2024, Ken Matsui wrote: > > > This patch implements a --num-commits (-n) flag for shorthand for > > the range of hash~N..hash commits. Ping. > > > > contrib/ChangeLog: > > > > * gcc-changelog/git_check_commit.py:

Re: [PATCH] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, 14 Mar 2024, Jakub Jelinek wrote: > Hi! > > This patch (on top of the just posted gsi_safe_insert* fixes patch) > fixes the instrumentation of large/huge _BitInt SSA_NAME arguments of > returns_twice calls. > > In this case it isn't just a matter of using gsi_safe_insert_before instead

Re: [PATCH] vect: Call vect_convert_output with the right vecitype [PR114108]

On Thu, Mar 14, 2024 at 11:14 AM Tejas Belagod wrote: > > > Ping. > > Thanks, > Tejas. > > On 3/13/24 6:07 PM, Tejas Belagod wrote: > > Ping! > > > > On 3/7/24 4:14 PM, Tejas Belagod wrote: > >> This patch fixes a bug where vect_recog_abd_pattern called > >> vect_convert_output > >> with the

Re: Re: [PATCH] RISC-V: Introduce option -mrvv-autovec-max-lmul for RVV autovec

>> This PR is not really resolved or affected by the patch if I'm not >>mistaken. We still have code paths that will generate a larger LMUL >>(also in vsetvl last I checked, but that was a while ago). Ok. we should only mention PR target/112651 which is enough. >>Should it really be called

Re: [PATCH v2] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

On Sat, Mar 2, 2024 at 5:04 AM Ken Matsui wrote: > > This patch adds a warning switch for "#pragma once in main file". The > warning option name is Wpragma-once-outside-header, which is the same > as Clang. Ping. > > PR preprocessor/89808 > > gcc/c-family/ChangeLog: > > *

[PATCH] gimple-iterator: Some gsi_safe_insert_*before fixes

Hi! When trying to use the gsi_safe_insert*before APIs in bitint lowering, I've discovered 3 issues and the following patch addresses those: 1) both split_block and split_edge update CDI_DOMINATORS if they are available, but because edge_before_returns_twice_call first splits and then adds

Re: [PATCH] gimple-iterator: Some gsi_safe_insert_*before fixes

On Thu, 14 Mar 2024, Jakub Jelinek wrote: > Hi! > > When trying to use the gsi_safe_insert*before APIs in bitint lowering, > I've discovered 3 issues and the following patch addresses those: > > 1) both split_block and split_edge update CDI_DOMINATORS if they are >available, but because

Re: [PATCH] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote: > Ugh. OK, but I wonder whether we might want to simply delay > fixing the CFG for inserts before returns-twice? Would that make > things less ugly? You mean in lower_call just remember if we added anything before ECF_RETURNS_TWICE

Re: [PATCH] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, 14 Mar 2024, Jakub Jelinek wrote: > On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote: > > Ugh. OK, but I wonder whether we might want to simply delay > > fixing the CFG for inserts before returns-twice? Would that make > > things less ugly? > > You mean in lower_call just

Re: [PATCH] i386[stv]: Handle REG_EH_REGION note

On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote: > > When we split > (insn 37 36 38 10 (set (reg:DI 104 [ _18 ]) > (mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct > SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])) "test.C":22:42 84 > {*movdi_internal} >

Re: [PATCH V12]: Improve code sinking pass

On Wed, Mar 13, 2024 at 9:27 PM Jeff Law wrote: > > > > On 3/13/24 4:22 AM, Richard Biener wrote: > > > > > ... this hunk is OK (please test and split it out separatley). In the > > spirit of > > moving the stmt the least amount (in this case not schedule it within the > > basic-block). In the

[Committed] IBM Z: Fix -munaligned-symbols

With this fix we make sure that only symbols with a natural alignment smaller than 2 are considered misaligned with -munaligned-symbols. Background is that -munaligned-symbols is only supposed to affect symbols whose natural alignment wouldn't be enough to fulfill our ABI requirement of having all

[PATCH] bitint, v2: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, Mar 14, 2024 at 09:59:12AM +0100, Richard Biener wrote: > On Thu, 14 Mar 2024, Jakub Jelinek wrote: > > > On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote: > > > Ugh. OK, but I wonder whether we might want to simply delay > > > fixing the CFG for inserts before

[PATCH v2 02/12] extend.texi: Add documentation for __is_array

gcc/ChangeLog: * doc/extend.texi (__is_array): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index b13f9d6f934..5aeb9bdd47a 100644 --- a/gcc/doc/extend.texi +++

Re: [PATCH] LoongArch: Remove unused and incorrect "sge_" define_insn

在 2024/3/13 下午9:03, Xi Ruoyao 写道: If this insn is really used, we'll have something like slti $r4,$r0,$r5 in the code. The assembler will reject it because slti wants 2 register operands and 1 immediate operand. But we've not got any bug report for this, indicating this define_insn is

[PATCH v2 12/12] extend.texi: Add subsections for type- and expression-yielding traits

gcc/ChangeLog: * doc/extend.texi (Expression-yielding Type Traits): New subsection. (Type-yielding Type Traits): Likewise. (__remove_pointer): Move under the Type-yielding Type Traits subsection. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 18

[PATCH v2 11/12] extend.texi: Add documentation for __remove_pointer

gcc/ChangeLog: * doc/extend.texi (__remove_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index e4a4060be2b..10ddf50182d 100644 --- a/gcc/doc/extend.texi

Re: [PATCH] match.pd: Only merge truncation with conversion for -fno-signed-zeros

On Wed, Mar 13, 2024 at 3:39 PM Joe Ramsay wrote: > > This optimisation does not honour signed zeros, so should not be > enabled except with -fno-signed-zeros. > > OK for master? I do not have commit rights for GCC, so if the patch > is fine would someone be able to commit for me? The bug is

Re: [PATCH] RISC-V: Introduce option -mrvv-autovec-max-lmul for RVV autovec

Should it really be called autovec-max-lmul? We also use TARGET_MAX_LMUL for builtins etc. Or are we just following LLVM's naming here? Isn't -mrvv-max-lmul sufficient? > PR target/112648 This PR is not really resolved or affected by the

[PATCH v2 09/12] extend.texi: Add documentation for __is_reference

gcc/ChangeLog: * doc/extend.texi (__is_reference): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 293eb5706f9..6af5294c7b0 100644 --- a/gcc/doc/extend.texi +++

[PATCH v2 07/12] extend.texi: Add documentation for __is_member_pointer

gcc/ChangeLog: * doc/extend.texi (__is_member_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 7644ea5b80b..86ac0c7ed07 100644 ---

[PATCH v2 08/12] extend.texi: Add documentation for __is_object

gcc/ChangeLog: * doc/extend.texi (__is_object): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 86ac0c7ed07..293eb5706f9 100644 --- a/gcc/doc/extend.texi +++

[PATCH] bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

Hi! This patch (on top of the just posted gsi_safe_insert* fixes patch) fixes the instrumentation of large/huge _BitInt SSA_NAME arguments of returns_twice calls. In this case it isn't just a matter of using gsi_safe_insert_before instead of gsi_insert_before, we need to do more. One thing is

[PATCH v2 05/12] extend.texi: Add documentation for __is_member_function_pointer

gcc/ChangeLog: * doc/extend.texi (__is_member_function_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index a94ad7955fe..f08574318d0 100644 ---

[PATCH v2 10/12] extend.texi: Add documentation for __is_scoped_enum

gcc/ChangeLog: * doc/extend.texi (__is_scoped_enum): New documentation. (__is_enum): Add @anchor to get linked from __is_scoped_enum. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 9 + 1 file changed, 9 insertions(+) diff --git a/gcc/doc/extend.texi

[PATCH v2 01/12] extend.texi: Arrange pre-existing built-in traits alphabetically

Ok for trunk? -- >8 -- This patch arranges pre-existing built-in traits alphabetically for better codebase consistency and easier future integration of changes. gcc/ChangeLog: * doc/extend.texi (Type Traits): Arrange pre-existing built-in traits alphabetically. Signed-off-by:

[PATCH v2 03/12] extend.texi: Add documentation for __is_bounded_array

gcc/ChangeLog: * doc/extend.texi (__is_bounded_array): New documentation. (__is_array): Add @anchor to get linked from __is_bounded_array. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 9 + 1 file changed, 9 insertions(+) diff --git a/gcc/doc/extend.texi

[PATCH v2 06/12] extend.texi: Add documentation for __is_member_object_pointer

gcc/ChangeLog: * doc/extend.texi (__is_member_object_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index f08574318d0..7644ea5b80b 100644 ---

Re: [PATCH v2 01/12] extend.texi: Arrange pre-existing built-in traits alphabetically

On Thu, Mar 14, 2024 at 12:28 AM Ken Matsui wrote: > > Ok for trunk? It appears that my update notes have somehow vanished. I have rectified several inconsistencies and introduced sub-sections to enhance readability. Although I contemplated merging certain patches for a more streamlined

[PATCH] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

Hi! The following testcase ICEs with LSE atomics. The problem is that the @atomic_compare_and_swap expander uses aarch64_reg_or_zero predicate for the desired operand, which is fine, given that for most of the modes and even for TImode in some cases it can handle zero immediate just fine, but the

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> This patch corrects bugs within the CO-RE builtin field expression > related builtins. > The following bugs were identified and corrected based on the expected > results of bpf-next selftests testsuite. > It addresses the following problems: > - Expressions with pointer dereferencing now

[PATCH v2] match.pd: Only merge truncation with conversion for -fno-signed-zeros

This optimisation does not honour signed zeros, so should not be enabled except with -fno-signed-zeros. OK for master? I do not have commit rights for GCC, so if the patch is fine would someone be able to commit for me? The bug is present in all GCC versions from 12.1.0 onwards - is it possible

Re: [PATCH] vect: Call vect_convert_output with the right vecitype [PR114108]

Ping. Thanks, Tejas. On 3/13/24 6:07 PM, Tejas Belagod wrote: Ping! On 3/7/24 4:14 PM, Tejas Belagod wrote: This patch fixes a bug where vect_recog_abd_pattern called vect_convert_output with the incorrect vecitype for the corresponding pattern_stmt. vect_convert_output expects vecitype

Re: [PATCH] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

On 14/03/2024 08:37, Jakub Jelinek wrote: Hi! The following testcase ICEs with LSE atomics. The problem is that the @atomic_compare_and_swap expander uses aarch64_reg_or_zero predicate for the desired operand, which is fine, given that for most of the modes and even for TImode in some cases

Re: [PATCH] i386[stv]: Handle REG_EH_REGION note

On Thu, Mar 14, 2024 at 8:42 AM Uros Bizjak wrote: > > On Thu, Mar 14, 2024 at 8:32 AM Hongtao Liu wrote: > > > > On Thu, Mar 14, 2024 at 3:22 PM Uros Bizjak wrote: > > > > > > On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote: > > > > > > > > When we split > > > > (insn 37 36 38 10 (set (reg:DI

[committed] libstdc++: Correct notes about std::call_once in manual [PR66146]

Pushed to trunk. I should backport this too. -- >8 -- The bug with exceptions thrown during a std::call_once call affects all targets, so fix the docs that say it only affects non-Linux targets. libstdc++-v3/ChangeLog: PR libstdc++/66146 * doc/xml/manual/status_cxx2011.xml:

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

>> Jose E. Marchesi writes: >> This patch corrects bugs within the CO-RE builtin field expression related builtins. The following bugs were identified and corrected based on the expected results of bpf-next selftests testsuite. It addresses the following problems:

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > int test (int a) > > { > > return a>0 ? CST1: CST2; > > } > > > > gets same hash value no matter what CST1/CST2 is. I added hasher and I > > am re-running stats. > > The hash should be commutative here at least. It needs to match what comparator is doing later, and sadly it does not try

OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing (was: [PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends)

Hi! On 2024-03-13T10:12:17+0100, I wrote: > On 2024-03-07T17:02:02+0900, Chung-Lin Tang > wrote: >> Also added simple 'declare' tests, but there is not anything to scan in the >> 'tree-original' dump though. > > Yeah, the current OpenACC 'declare' implementation is "special". Actually --

Re: [PATCH v2] openmp: Change to using a hashtab to lookup offload target addresses for indirect function calls

Hi Kwok, On January 22, 2024, Kwok Cheung Yeung wrote: There was a bug in the declare-target-indirect-2.c libgomp testcase (testing indirect calls in offloaded target regions, spread over multiple teams/threads) that due to an errant fallthrough in a switch statement resulted in only one

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> Jose E. Marchesi writes: > >>> This patch corrects bugs within the CO-RE builtin field expression >>> related builtins. >>> The following bugs were identified and corrected based on the expected >>> results of bpf-next selftests testsuite. >>> It addresses the following problems: >>> -

Re: [PATCH] bitint, v2: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]

On Thu, 14 Mar 2024, Jakub Jelinek wrote: > On Thu, Mar 14, 2024 at 09:59:12AM +0100, Richard Biener wrote: > > On Thu, 14 Mar 2024, Jakub Jelinek wrote: > > > > > On Thu, Mar 14, 2024 at 09:48:45AM +0100, Richard Biener wrote: > > > > Ugh. OK, but I wonder whether we might want to simply delay

[committed] libstdc++: Update C++23 status in the manual

I think we have all C++23 changes in this table now. At some point soon we should replace the C++20 table of papers with the C++20 table of contents, as we do for the other standards. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2023.xml: Update C++23

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

Jose E. Marchesi writes: >> This patch corrects bugs within the CO-RE builtin field expression >> related builtins. >> The following bugs were identified and corrected based on the expected >> results of bpf-next selftests testsuite. >> It addresses the following problems: >> - Expressions

Re: [PATCH] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

On Thu, Mar 14, 2024 at 11:49:14AM +, Richard Earnshaw (lists) wrote: > On 14/03/2024 08:37, Jakub Jelinek wrote: > > Hi! > > > > The following testcase ICEs with LSE atomics. > > The problem is that the @atomic_compare_and_swap expander uses > > aarch64_reg_or_zero predicate for the desired

Here's the document that was shared with you.

test

Re: [PATCH] libstdc++: atomic: Add missing clear_padding in __atomic_float constructor

On Fri, 16 Feb 2024 at 15:15, Jonathan Wakely wrote: > > On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote: > > > > On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote: > > > Ah, although __atomic_compare_exchange only takes pointers, the > > > compiler replaces that with a call to

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > We have wrong code with LTO, too. > > I know. > > > The problem is that IPA passes (and > > not only that, loop analysis too) does analysis at compile time (with > > value numbers in) and streams the info separately. > > And that is desirable, because otherwise it simply couldn't derive any

[PATCH] bpf: define INT8_TYPE as signed char

Change the BPF backend to define INT8_TYPE with an explicit sign, rather than a plain char. This is in line with other targets and removes the risk of int8_t being affected by the signedness of the plain char type of the host system. Tested on x86_64-linux-gnu host for bpf-unknown-none. Sanity

Re: OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

Hi all, hi Thomas & Chung-Lin, Thomas Schwinge wrote: But I realized another thing: don't we have to handle the 'readonly' modifier also in Fortran module files, that is, next to the OpenACC 'declare' 'copyin' handling in 'gcc/fortran/module.cc': 'AB_OACC_DECLARE_COPYIN' etc.? I bet so; it is

Re: OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

Hi all, hi Thomas & Chung-Lin, Thomas Schwinge wrote: But I realized another thing: don't we have to handle the 'readonly' modifier also in Fortran module files, that is, next to the OpenACC 'declare' 'copyin' handling in 'gcc/fortran/module.cc': 'AB_OACC_DECLARE_COPYIN' etc.? I bet so; it is

[committed] gcn: Fix a comment typo

Hi! I've noticed a typo in the comment above ABI_VERSION_SPEC. Fixed thusly, committed to trunk as obvious. 2024-03-14 Jakub Jelinek * config/gcn/gcn-hsa.h (ABI_VERSION_SPEC): Fix comment typo. --- gcc/config/gcn/gcn-hsa.h.jj 2024-01-27 13:03:55.589073484 +0100 +++

[committed] libstdc++: Fix std::format("{}", negative_integer) [PR114325]

Tested aarch64-linux. Pushed to trunk. -- >8 -- The fast path for "{}" format strings has a bug for negative integers where the length passed to std::to_chars is too long. libstdc++-v3/ChangeLog: PR libstdc++/114325 * include/std/format (_Scanner::_M_scan): Pass correct length

Re: [PATCH] bpf: define INT8_TYPE as signed char

Hi David. > Change the BPF backend to define INT8_TYPE with an explicit sign, rather > than a plain char. This is in line with other targets and removes the > risk of int8_t being affected by the signedness of the plain char type > of the host system. OK. I would add to the commit message

[PATCH] libstdc++: Suppress deprecation messages from [PR101228]

Should we do this to silence the deprecation messages from the TBB headers we include? -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/101228 * include/pstl/parallel_backend_tbb.h (TBB_SUPPRESS_DEPRECATED_MESSAGES): Define before including then undef afterwards. ---

[PATCH] vect: Use xor to invert oversized vector masks

Don't enable excess lanes when inverting vector bit-masks smaller than the integer mode. This is yet another case of wrong-code due to mishandling of oversized bitmasks. This issue shows up in vect/tsvc/vect-tsvc-s278.c and vect/tsvc/vect-tsvc-s279.c if I set the preferred vector size to V32

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > Otherwise > > I will add your testcase for this patch and commit this one. > > Statistically we almost never merge functions with different value > > ranges (three in testsuite, 0 during bootstrap, 1 during LTO bootstrap > > and probably few in LLVM build - there are 15 cases reported, but

Re: [PATCH] Fix PR ipa/113996

> > Patch is still OK, but ipa-ICF will only identify the functions if > > static chain is unused. Perhaps just picking the winning candidate to be > > version without static chain and making ipa-inline to not ICE when calls > > with static chain lands to function with no static chain would help

[committed] libstdc++: Add nodiscard in

Tested aarch64-linux and x86_64-linux. Pushed to trunk. I forgot to update the commit log to remove the speculation, because Stephan Lavavej confirmed that MSVC doesn't mark those functions nodiscard because it would result in too many false positives. Although it might find some real bugs, it

Re: [PATCH] bpf: define INT8_TYPE as signed char

On 3/14/24 10:16, Jose E. Marchesi wrote: > > Hi David. > >> Change the BPF backend to define INT8_TYPE with an explicit sign, rather >> than a plain char. This is in line with other targets and removes the >> risk of int8_t being affected by the signedness of the plain char type >> of the

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Thu, Mar 14, 2024 at 05:16:59PM +0100, Jan Hubicka wrote: > Sorry, this was bit of a misunderstanding: I tought you still considered > the original patch to be full fix, while I tought I should look into it > more and dig out more issues. This is bit of can of worms. Overall I > think the

[PATCH] gcc: xtensa: reorder movsi_internal patterns for better code generation during LRA

After switching to LRA xtensa backend generates the following code for saving/loading registers: movi a9, 0x190 add a9, a9, sp s32i.n a3, a9, 0 instead of the shorter and more efficient s32i a3, a9, 0x190 E.g. the following code can be used to reproduce it:

[PATCH RFA] tree-core: clarify clobber comments

OK for trunk? -- 8< -- It came up on the mailing list that OBJECT_BEGIN/END are described as marking object lifetime, but mark the beginning of the constructor and end of the destructor, whereas the C++ notion of lifetime is between the end of the constructor and beginning of the destructor. So

[committed] hppa: Fix REG+D address support before reload

Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- hppa: Fix REG+D address support before reload When generating PA 1.x code or code for GNU ld, floating-point accesses only support 5-bit displacements but integer accesses support 14-bit displacements. I mistakenly assumed reload

Re: [PATCH] c++: explicit inst of template method not generated [PR110323]

On 3/8/24 12:02, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Consider constexpr int VAL = 1; struct foo { template void bar(typename std::conditional::type arg) { } }; template void foo::bar<1>(int arg); where we since

Re: [PATCH RFA] tree-core: clarify clobber comments

On Thu, Mar 14, 2024 at 04:27:22PM -0400, Jason Merrill wrote: > OK for trunk? > > -- 8< -- > > It came up on the mailing list that OBJECT_BEGIN/END are described as > marking object lifetime, but mark the beginning of the constructor and end > of the destructor, whereas the C++ notion of

Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

Hi This is what I started to do. For now I haven't touch to __cpp_lib_null_iterators definition as _Safe_local_iterator still need some work. libstdc++: Implement N3644 on _Safe_iterator<> [PR114316] Consider range of value-initialized iterators as valid and empty. libstdc++-v3/ChangeLog:

[PATCH v3] c++: ICE with temporary of class type in array DMI [PR109966]

On Tue, Mar 12, 2024 at 06:26:14PM -0400, Jason Merrill wrote: > On 3/12/24 11:56, Marek Polacek wrote: > > On Tue, Mar 12, 2024 at 09:57:14AM -0400, Jason Merrill wrote: > > > On 3/11/24 19:27, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > >

C/C++ frontend patches ping

musttail support for C/C++ https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643867.html Support constexpr for asm statements in C++ https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643933.html

Re: C/C++ frontend patches ping

On Thu, Mar 14, 2024 at 9:36 PM Andi Kleen wrote: > > > musttail support for C/C++ > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643867.html > > > Support constexpr for asm statements in C++ > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643933.html Both of these were

Re: C/C++ frontend patches ping

Andrew Pinski writes: > On Thu, Mar 14, 2024 at 9:36 PM Andi Kleen wrote: >> >> >> musttail support for C/C++ >> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643867.html >> >> >> Support constexpr for asm statements in C++ >> >>

Re: [PATCH] i386[stv]: Handle REG_EH_REGION note

On Thu, Mar 14, 2024 at 10:46 PM Uros Bizjak wrote: > > On Thu, Mar 14, 2024 at 8:42 AM Uros Bizjak wrote: > > > > On Thu, Mar 14, 2024 at 8:32 AM Hongtao Liu wrote: > > > > > > On Thu, Mar 14, 2024 at 3:22 PM Uros Bizjak wrote: > > > > > > > > On Thu, Mar 14, 2024 at 2:33 AM liuhongt wrote:

[PATCH v2 3/3] LoongArch: Combine UNITS_PER_FP_REG and UNITS_PER_FPREG macros.

These macros are completely same in definition, so we can keep the previous one and eliminate later one. gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_hard_regno_mode_ok_uncached): Combine UNITS_PER_FP_REG and UNITS_PER_FPREG macros.

[PATCH v2 1/3] LoongArch: Remove unused/useless definitions.

This patch removes some unnecessary definitions of target hook functions according to the documentation of GCC. gcc/ChangeLog: * config/loongarch/loongarch-protos.h (loongarch_cfun_has_cprestore_slot_p): Delete. (loongarch_adjust_insn_length): Delete.

[PATCH v2 2/3] LoongArch: Change loongarch_expand_vec_cmp()'s return type from bool to void.

This function is always return true at the end of function implementation, so the return value is useless. gcc/ChangeLog: * config/loongarch/lasx.md (vec_cmp): Remove checking of loongarch_expand_vec_cmp()'s return value. (vec_cmpu): Ditto. *

Re: [PATCH v14 23/26] c++: Implement __is_invocable built-in trait

On Fri, Mar 8, 2024 at 9:17 AM Patrick Palka wrote: > > On Wed, 28 Feb 2024, Ken Matsui wrote: > > > This patch implements built-in trait for std::is_invocable. > > > > gcc/cp/ChangeLog: > > > > * cp-trait.def: Define __is_invocable. > > * constraint.cc (diagnose_trait_expr): Handle

Re: [PATCH v1] libstdc++: Optimize removal from unique assoc containers [PR112934]

Hi 2024. március 13., szerda 12:43 keltezéssel, Jonathan Wakely írta: > On Mon, 11 Mar 2024 at 23:36, Barnabás Pőcze wrote: > > > > Previously, calling erase(key) on both std::map and std::set > > would execute that same code that std::multi{map,set} would. > > However, doing that is

Re: [PATCH] vect: Use xor to invert oversized vector masks

On Thu, Mar 14, 2024 at 11:42 PM Andrew Stubbs wrote: > > Don't enable excess lanes when inverting vector bit-masks smaller than the > integer mode. This is yet another case of wrong-code due to mishandling > of oversized bitmasks. > > This issue shows up in vect/tsvc/vect-tsvc-s278.c and >

Re:[pushed] [PATCH v2] LoongArch: Remove masking process for operand 3 of xvpermi.q.

Pushed to r14-9486. 在 2024/3/14 上午9:26, Chenghui Pan 写道: The behavior of non-zero unused bits in xvpermi.q instruction's third operand is undefined on LoongArch, according to our discussion (https://github.com/llvm/llvm-project/pull/83540), we think that keeping original insn operand as

[PATCH v2 0/3] LoongArch: Cleanup unused/redundant codes.

Changes from v1: Some correction about ChangeLog format. There's some unused/redundant definitions inside LoongArch target support codes, these patches make a simple cleanup. Regression test passed. Chenghui Pan (3): LoongArch: Remove unused/useless definitions. LoongArch: Change

RE: [PATCH v3] RISC-V: Introduce gcc attribute riscv_rvv_vector_bits for RVV

> Shouldn't a major user-facing change like this be discussed in a PR against > https://github.com/riscv-non-isa/riscv-c-api-doc/ or > https://github.com/riscv-non-isa/rvv-intrinsic-doc before or concurrent with > compiler implementation? I think Kito is working on the spec doc already. Hi Kito

[r14-9478 Regression] FAIL: g++.dg/torture/pr104601.C -Os (test for excess errors) on Linux/x86_64

On Linux/x86_64, df483ebd24689a3bebfae2089637a00eca0e5a12 is the first bad commit commit df483ebd24689a3bebfae2089637a00eca0e5a12 Author: Jonathan Wakely Date: Mon Feb 26 13:17:13 2024 + libstdc++: Add nodiscard in caused FAIL: g++.dg/torture/pr104601.C -O0 (test for excess