Re: [PATCH v2] RISC-V: Support scheduling for sifive p600 series

Hi Juzhe, The vector part is complicated, I will add it last. On Thu, Feb 1, 2024 at 11:08 AM juzhe.zh...@rivai.ai wrote: > Hi, Monk. > > This model doesn't include vector. Will you add vector pipeline in the > followup patches ? > > -- > juzhe.zh...@rivai.ai >

Re: Re: [PATCH v2] RISC-V: Support scheduling for sifive p600 series

Thanks. I wonder whether p600 will enable dynamic lmul by default ? Does dynamic LMUL help with sifive p600 chip ? juzhe.zh...@rivai.ai From: Monk Chiang Date: 2024-02-01 16:10 To: juzhe.zh...@rivai.ai CC: gcc-patches; kito.cheng Subject: Re: [PATCH v2] RISC-V: Support scheduling for sifive p6

Re: [PATCH] libgcc: Avoid warnings on __gcc_nested_func_ptr_created [PR113402]

On Wed, Jan 31, 2024 at 01:04:20PM +0100, Jakub Jelinek wrote: > On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote: > > * config/aarch64/heap-trampoline.c: Rename > > __builtin_nested_func_ptr_created to __gcc_nested_func_ptr_created and > > __builtin_nested_func_ptr_deleted t

Re: [PATCH] libgcc: Fix up i386/t-heap-trampoline [PR113403]

On Wed, Jan 31, 2024 at 12:59:27PM +0100, Jakub Jelinek wrote: > On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote: > > --- a/libgcc/config/aarch64/t-heap-trampoline > > +++ b/libgcc/config/aarch64/t-heap-trampoline > > @@ -16,4 +16,5 @@ > > # along with GCC; see the file COPYING3. If n

Re: [PATCH] varasm, v3: Handle private COMDAT function symbol reference in readonly data section [PR113617]

On Wed, Jan 31, 2024 at 07:58:50PM +0100, Jakub Jelinek wrote: > On Wed, Jan 31, 2024 at 07:11:20PM +0100, Jakub Jelinek wrote: > > On Wed, Jan 31, 2024 at 09:39:12AM -0800, H.J. Lu wrote: > > > GNU binutils has no issues with it: > > > > I know, I meant gcc. > > So, it seems get_section handles s

[PATCH] RISC-V: Add minimal support for 7 new unprivileged extensions

The RISC-V Profiles specification here: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions These extensions don't add any new features but describe existing features. So this patch only adds parsing. Za64rs: Reservation set size of 64 bytes Za128rs: Reservation s

Re: [PATCH] RISC-V: Add minimal support for 7 new unprivileged extensions

Could you add some document for doc/invoke.texi, I just added a list for listing all supported extensions before[1]. [1] https://github.com/gcc-mirror/gcc/commit/19260a04ba6f75b1fae52afab50dcb43d44eb259 On Thu, Feb 1, 2024 at 4:29 PM Monk Chiang wrote: > > The RISC-V Profiles specification here

[PATCH] RISC-V: Disable the vsetvl fusion for conflict successors

This patch fixes the following ineffective vsetvl insertion: #include "riscv_vector.h" void f (int32_t * restrict in, int32_t * restrict out, size_t n, size_t cond, size_t cond2) { for (size_t i = 0; i < n; i++) { if (i == cond) { vint8mf8_t v = *(vint8mf8_t*)(in + i + 100);

Re: [PATCH] libgcc: Avoid warnings on __gcc_nested_func_ptr_created [PR113402]

On Thu, Feb 1, 2024 at 9:23 AM Jakub Jelinek wrote: > > On Wed, Jan 31, 2024 at 01:04:20PM +0100, Jakub Jelinek wrote: > > On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote: > > > * config/aarch64/heap-trampoline.c: Rename > > > __builtin_nested_func_ptr_created to __gcc_nested_f

Re: [PATCH] RISC-V: Add minimal support for 7 new unprivileged extensions

On Thu, Feb 1, 2024 at 10:43 AM Kito Cheng wrote: > Could you add some document for doc/invoke.texi, I just added a list > for listing all supported extensions before[1]. > > [1] > https://github.com/gcc-mirror/gcc/commit/19260a04ba6f75b1fae52afab50dcb43d44eb259 Offtopic, but looking at the fil

[PATCH v2] RISC-V: Suppress the vsetvl fusion for conflict successors

Update in v2: Add dump information. This patch fixes the following ineffective vsetvl insertion: #include "riscv_vector.h" void f (int32_t * restrict in, int32_t * restrict out, size_t n, size_t cond, size_t cond2) { for (size_t i = 0; i < n; i++) { if (i == cond) { vint8mf8

[PATCH v2] RISC-V: Add minimal support for 7 new unprivileged extensions

The RISC-V Profiles specification here: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions These extensions don't add any new features but describe existing features. So this patch only adds parsing. Za64rs: Reservation set size of 64 bytes Za128rs: Reservation s

[PATCH]AArch64: update vget_set_lane_1.c test output

Hi All, In the vget_set_lane_1.c test the following entries now generate a zip1 instead of an INS BUILD_TEST (float32x2_t, float32x2_t, , , f32, 1, 0) BUILD_TEST (int32x2_t, int32x2_t, , , s32, 1, 0) BUILD_TEST (uint32x2_t, uint32x2_t, , , u32, 1, 0) This is because the non-Q variant for

Re: [PATCH]AArch64: update vget_set_lane_1.c test output

On Thu, Feb 1, 2024 at 1:26 AM Tamar Christina wrote: > > Hi All, > > In the vget_set_lane_1.c test the following entries now generate a zip1 > instead of an INS > > BUILD_TEST (float32x2_t, float32x2_t, , , f32, 1, 0) > BUILD_TEST (int32x2_t, int32x2_t, , , s32, 1, 0) > BUILD_TEST (uint32x2_

[PATCH] tree-optimization/113693 - LC SSA and region VN

The following fixes LC SSA preserving with region VN which was broken when availability checking was enhanced to treat not visited value numbers as available. The following makes sure to honor availability data we put in place for LC SSA preserving instead. Bootstrapped and tested on x86_64-unkno

Re: [PATCH v2] mklog: Add lookup for new generated files in libstdc++

On Tue, 30 Jan 2024 at 21:35, Jonathan Wakely wrote: > > On 30/01/24 15:02 +, Jonathan Wakely wrote: > >That way other subdirectories could add their own extra generated files to > >it. > > Like so. > > mklog: Add lookup for generated files in specific sub-directories > > The mklog.p

GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'

Hi! On 2024-01-31T11:31:00+, Andrew Stubbs wrote: > On 31/01/2024 10:36, Thomas Schwinge wrote: >> OK to push "GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'", >> see attached? >> >> In pre-RDNA 3 ISA manuals, there are notes for 'DS_CMPST_[...]', like: >> >> Caution, the order o

Re: GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'

On 01/02/2024 11:36, Thomas Schwinge wrote: Hi! On 2024-01-31T11:31:00+, Andrew Stubbs wrote: On 31/01/2024 10:36, Thomas Schwinge wrote: OK to push "GCN, RDNA 3: Adjust 'sync_compare_and_swap_lds_insn'", see attached? In pre-RDNA 3 ISA manuals, there are notes for 'DS_CMPST_[...]', like

[COMMITTED] Link shared libasan with -z now on Solaris

g++.dg/asan/default-options-1.C FAILs on Solaris/SPARC and x86: FAIL: g++.dg/asan/default-options-1.C -O0 execution test FAIL: g++.dg/asan/default-options-1.C -O1 execution test FAIL: g++.dg/asan/default-options-1.C -O2 execution test FAIL: g++.dg/asan/default-options-1.C -O2 -flto exe

Re: Unreviewed patches

Hi Uros, > On Wed, Jan 31, 2024 at 3:04 PM Rainer Orth > wrote: >> >> Three patches have remained unreviewed for a week or more: >> >> c++: Fix g++.dg/ext/attr-section2.C etc. with Solaris/SPARC as >> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643434.html >> >> This o

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

Hi Lewis, > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: >> On 12/5/23 20:52, Lewis Hyatt wrote: >> > Hello- >> > >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 >> > >> > There are two related issues here really, a regression since GCC 11 where >> > we >> > can ICE a

[PATCH] RISC-V: Remove vsetvl_pre bogus instructions in VSETVL PASS

I realize there is a RTL regression between GCC-14 and GCC-13. https://godbolt.org/z/Ga7K6MqaT GCC-14: (insn 9 13 31 2 (set (reg:DI 15 a5 [138]) (unspec:DI [ (const_int 64 [0x40]) ] UNSPEC_VLMAX)) "/app/example.c":5:15 2566 {vlmax_avldi} (expr_list:REG_EQUI

Re: [PATCH v2] RISC-V: Add minimal support for 7 new unprivileged extensions

Pushed to trunk, thanks :) On Thu, Feb 1, 2024 at 5:16 PM Monk Chiang wrote: > > The RISC-V Profiles specification here: > https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions > > These extensions don't add any new features but > describe existing features. So this

Re: [PATCH] RISC-V: Remove vsetvl_pre bogus instructions in VSETVL PASS

LGTM On Thu, Feb 1, 2024 at 8:25 PM Juzhe-Zhong wrote: > > I realize there is a RTL regression between GCC-14 and GCC-13. > https://godbolt.org/z/Ga7K6MqaT > > GCC-14: > (insn 9 13 31 2 (set (reg:DI 15 a5 [138]) > (unspec:DI [ > (const_int 64 [0x40]) > ] UNSPEC

Re: [PATCH] RISC-V: Remove vsetvl_pre bogus instructions in VSETVL PASS

> +static bool > +vsetvl_pre_insn_p (rtx_insn *rinsn) > +{ > + return recog_memoized (rinsn) >= 0 > + && get_attr_type (rinsn) == TYPE_VSETVL_PRE; > +} Indent looks off on my screen. Can you check? Apart from that LGTM (no need for v2 of course). Regards Robin

[PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

Attached patch OK? Copied inline for review convenience. diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..e966afe6cdc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 &&

Re: [PATCH v2] RISC-V: Support scheduling for sifive p600 series

thanks, pushed to trunk :) On Thu, Feb 1, 2024 at 11:02 AM Monk Chiang wrote: > > Add sifive p600 series scheduler module. For more information > see https://www.sifive.com/cores/performance-p650-670. > Add sifive-p650, sifive-p670 for mcpu option will come in separate patches. > > gcc/ChangeLog:

Re: Re: [PATCH v2] RISC-V: Support scheduling for sifive p600 series

Yeah, that's the plan for the longer term, we would like to build the schedule model first and then run more benchmarks with that, then enable dynamic lmul by default, most SiFive cores prefer larger LMUL if possible/no spill. On Thu, Feb 1, 2024 at 4:14 PM juzhe.zh...@rivai.ai wrote: > > Thanks.

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: > Attached patch OK? Copied inline for review convenience. No, I think e.g. AIX doesn't support the z modifier. I don't see %zd or %zu used anywhere except in gcc/jit/ which presumably doesn't work on AIX. If you really want to avoid

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote: > On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: > > Attached patch OK? Copied inline for review convenience. > > No, I think e.g. AIX doesn't support the z modifier. > I don't see %zd or %zu used anywhere except in gcc/jit/ w

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 01, 2024 at 02:01:17PM +0100, Jakub Jelinek wrote: > On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: > > Attached patch OK? Copied inline for review convenience. > > No, I think e.g. AIX doesn't support the z modifier. > I don't see %zd or %zu used anywhere except in gcc

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On Thu, Feb 1, 2024 at 7:24 AM Rainer Orth wrote: > > Hi Lewis, > > > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: > >> On 12/5/23 20:52, Lewis Hyatt wrote: > >> > Hello- > >> > > >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 > >> > > >> > There are two related issues

Re: [PATCH v1] RISC-V: Cleanup the comments for the psabi

On 1/30/24 18:54, pan2...@intel.com wrote: From: Pan Li This patch would like to cleanup some comments which are out of date or incorrect. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_get_arg_info): Cleanup comments. (riscv_pass_by_reference): Ditto. (riscv_fntype

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On 2/1/24 13:06, Xi Ruoyao wrote: On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote: On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: Attached patch OK? Copied inline for review convenience. No, I think e.g. AIX doesn't support the z modifier. I don't see %zd or %zu used an

[PATCH] AArch64: memcpy/memset expansions should not emit LDP/STP [PR113618]

The new RTL introduced for LDP/STP results in regressions due to use of UNSPEC. Given the new LDP fusion pass is good at finding LDP opportunities, change the memcpy, memmove and memset expansions to emit single vector loads/stores. This fixes the regression and enables more RTL optimization on th

GCN: Don't hard-code number of SGPR/VGPR/AVGPR registers (was: [PATCH v3 05/10] GCN back-end code)

Hi! On 2018-12-12T11:52:52+, Andrew Stubbs wrote: > This patch contains the major part of the GCN back-end. [...] > --- /dev/null > +++ b/gcc/config/gcn/gcn.c > +void > +gcn_hsa_declare_function_name (FILE *file, const char *name, tree) > +{ > + /* Determine count of sgpr/vgpr registers

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

On Wed, 31 Jan 2024 at 17:20, xndcn wrote: > > Thanks! > > > Why not just use -latomic unconditionally here? > testsuites of libstdc++ seems to have some tricks to find and link > libatomic.a by using "dg-add-options libatomic", which do nothing for > x86 target. In previous email, we decide not t

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 01, 2024 at 01:42:03PM +, Jonathan Yong wrote: > On 2/1/24 13:06, Xi Ruoyao wrote: > > On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote: > > > On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: > > > > Attached patch OK? Copied inline for review convenience. > > >

[PATCH 1/2] target/113255 - avoid REG_POINTER on a pointer difference

The following avoids re-using a register holding a pointer (and thus might be REG_POINTER) for the result of a pointer difference computation. That might confuse heuristics in (broken) RTL alias analysis which relies on REG_POINTER indicating that we're dealing with one. This alone doesn't fix an

[PATCH 2/2] rtl-optimization/113255 - avoid re-associating REG_POINTER MINUS

The following avoids re-associating (minus:DI (reg/f:DI 119) (minus:DI (reg/f:DI 120) (reg/f:DI 114))) into (minus:DI (plus:DI (reg/f:DI 114) (reg/f:DI 119)) (reg/f:DI 120)) as that possibly confuses the REG_POINTER heuristics of RTL alias analysis. This happens to mi

Re: [PATCH]AArch64: update vget_set_lane_1.c test output

Andrew Pinski writes: > On Thu, Feb 1, 2024 at 1:26 AM Tamar Christina > wrote: >> >> Hi All, >> >> In the vget_set_lane_1.c test the following entries now generate a zip1 >> instead of an INS >> >> BUILD_TEST (float32x2_t, float32x2_t, , , f32, 1, 0) >> BUILD_TEST (int32x2_t, int32x2_t, ,

RE: [PATCH]AArch64: update vget_set_lane_1.c test output

> -Original Message- > From: Richard Sandiford > Sent: Thursday, February 1, 2024 2:24 PM > To: Andrew Pinski > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd > ; Richard Earnshaw ; Marcus > Shawcroft ; Kyrylo Tkachov > > Subject: Re: [PATCH]AArch64: update vget_set_lane_1.c test outp

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On 31/01/2024 15:53, Marek Polacek wrote: > On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote: > > Hi Marek, > > > > On 30/01/2024 13:15, Marek Polacek wrote: > > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > > > > On 1/25/24 20:36, Marek Polacek wrote: > > > > > Bet

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, 2024-02-01 at 14:55 +0100, Jakub Jelinek wrote: > On Thu, Feb 01, 2024 at 01:42:03PM +, Jonathan Yong wrote: > > On 2/1/24 13:06, Xi Ruoyao wrote: > > > On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote: > > > > On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: > > > >

libgomp GCN gfx1030/gfx1100 offloading status (was: [PATCH] amdgcn: additional gfx1100 support)

Hi! On 2024-01-26T10:45:10+0100, Richard Biener wrote: > On Fri, 26 Jan 2024, Richard Biener wrote: >> On Wed, 24 Jan 2024, Andrew Stubbs wrote: >> > [...] is enough to get gfx1100 working for most purposes, on top of the >> > patch that Tobias committed a week or so ago; there are still some tes

Re: GCN: Don't hard-code number of SGPR/VGPR/AVGPR registers

On 01/02/2024 13:49, Thomas Schwinge wrote: Hi! On 2018-12-12T11:52:52+, Andrew Stubbs wrote: This patch contains the major part of the GCN back-end. [...] --- /dev/null +++ b/gcc/config/gcn/gcn.c +void +gcn_hsa_declare_function_name (FILE *file, const char *name, tree) +{ + /*

Re: libgomp GCN gfx1030/gfx1100 offloading status (was: [PATCH] amdgcn: additional gfx1100 support)

On Thu, 1 Feb 2024, Thomas Schwinge wrote: > Hi! > > On 2024-01-26T10:45:10+0100, Richard Biener wrote: > > On Fri, 26 Jan 2024, Richard Biener wrote: > >> On Wed, 24 Jan 2024, Andrew Stubbs wrote: > >> > [...] is enough to get gfx1100 working for most purposes, on top of the > >> > patch that T

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On 2/1/24 14:33, Xi Ruoyao wrote: I mean if you are casting it to unsigned HOST_WIDE_INT, you should use HOST_WIDE_INT_PRINT_UNSIGNED, If you are casting it to size_t you cannot use it (as Jakub has explained). When you use printf-like things you have to keep the correspondence between format

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 01, 2024 at 02:13:11PM +0100, Jakub Jelinek wrote: > Or hwint.h could define PRIusize_t etc. macros and some corresponding type > to be used in casts, something like > #if SIZE_MAX == LONG_LONG_MAX > #define PRIusize_t HOST_LONG_LONG_FORMAT "u" > #define fmt_size_t unsigned long long >

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 01, 2024 at 02:53:47PM +, Jonathan Yong wrote: > On 2/1/24 14:33, Xi Ruoyao wrote: > > > > I mean if you are casting it to unsigned HOST_WIDE_INT, you should use > > HOST_WIDE_INT_PRINT_UNSIGNED, If you are casting it to size_t you > > cannot use it (as Jakub has explained). > >

Re: [PATCH 1/2] target/113255 - avoid REG_POINTER on a pointer difference

On Thu, Feb 1, 2024 at 3:18 PM Richard Biener wrote: > > The following avoids re-using a register holding a pointer (and > thus might be REG_POINTER) for the result of a pointer difference > computation. That might confuse heuristics in (broken) RTL alias > analysis which relies on REG_POINTER in

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote: > > This will run the test only once with -std=c++11. We'll get better coverage > > with dropping the line above and using > > > > /* { dg-do compile { target { tail_call && { c || c++11 } } } } */ > > > > but here it may not matter. >

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote: > No, besides the formatting being incorrect both in ChangeLog and in the > patch, this pessimizes ILP32 hosts unnecessarily. So like this instead? 2024-02-01 Jakub Jelinek * hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRI

[committed] libstdc++: Fix -Wdeprecated warning about implicit capture of 'this'

Tested x86_64-linux. Pushed to trunk. -- >8 -- In C++20 it's deprecated for a [=] lambda capture to capture the 'this' pointer. Using resize_and_overwrite with a lambda seems like overkill to write three chars to the string anyway. Just resize the string and overwrite the end of it directly. lib

[committed] libstdc++: Update expected error for debug/constexpr*_neg.cc tests

Tested x86_64-linux. Pushed to trunk. -- >8 -- We no longer hit a __builtin_unreachable() in these tests, so we need to update the dg-error patterns to match _Error_formatter::_M_error(). We can also remove some dg-prune-output directives matching notes saying "in 'constexpr' expansion" because

[committed] libstdc++: Do not use def-file-line for each macro in

Tested x86_64-linux. Pushed to trunk. -- >8 -- These line markers are not needed, because searching for a macro name works fine. Removing them means that small changes to do not result in large diffs to because of all the changed line numbers. libstdc++-v3/ChangeLog: * include/bits/v

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On 2/1/24 15:25, Jakub Jelinek wrote: On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote: No, besides the formatting being incorrect both in ChangeLog and in the patch, this pessimizes ILP32 hosts unnecessarily. So like this instead? 2024-02-01 Jakub Jelinek * hwint.h (

[PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence

Realize in recent benchmark evaluation (coremark-pro zip-test): vid.v v2 vmv.v.i v5,0 .L9: vle16.v v3,0(a4) vrsub.vxv4,v2,a6 ---> LICM failed to hoist it outside the loop. The root cause is: (insn 56 47 57 4 (set (subreg:DI (reg:HI 220) 0) (re

[PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

I plan to push this to trunk soon. CC HP for visibility of the change affecting cris-elf. In practice it shouldn't make any difference to any sensible code. It only affects C++20 mode (and later), and only changes the size of std::formatter objects which are typically only created by the library h

[PATCH 2/2] libstdc++: Handle encodings in localized chrono formatting [PR109162]

I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to be done now due to the ABI impact on cris-elf. This one could wait for stage 1. (HP, this one probably isn't of interest to you, but I don't know how to tell git-send-email to only CC you on the first patch). I'd like to do t

[PATCH v2] middle-end: Fix ICE in poly-int.h due to SLP.

Adds a check to ensure that the input vector arguments to a function are not variable length. Previously, only the output vector of a function was checked. The ICE in question is within the neon-sve-bridge.c test, and is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 gcc/ChangeLog

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

> From: Jonathan Wakely > Cc: Hans-Peter Nilsson > Date: Thu, 1 Feb 2024 15:36:50 + > I plan to push this to trunk soon. > > CC HP for visibility of the change affecting cris-elf. In practice it > shouldn't make any difference to any sensible code. It only affects > C++20 mode (and later),

[PATCH] aarch64: Fix ACLE SME streaming mode error in neon-sve-bridge

When using LTO, handling the pragma for sme before the pragma for the neon-sve-bridge caused the following error on svset_neonq, in the neon-sve-bridge.c test. error: ACLE function '0' can only be called when SME streaming mode is enabled. Handling the pragmas the other way around fixes this. No

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

On Feb 01 2024, Jonathan Wakely wrote: > This will result in an ABI change for targets that use 1-byte alignment > for all integral types, e.g. cris-elf. Or 2-byte alignment as on m68k. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0

Re: [PATCH]AArch64: update vget_set_lane_1.c test output

Tamar Christina writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Thursday, February 1, 2024 2:24 PM >> To: Andrew Pinski >> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd >> ; Richard Earnshaw ; Marcus >> Shawcroft ; Kyrylo Tkachov >> >> Subject: Re: [PATCH]AArch64:

Re: [PATCH v2] middle-end: Fix ICE in poly-int.h due to SLP.

Richard Ball writes: > Adds a check to ensure that the input vector arguments > to a function are not variable length. Previously, only the > output vector of a function was checked. > > The ICE in question is within the neon-sve-bridge.c test, > and is related to https://gcc.gnu.org/bugzilla/show

Re: [PATCH 2/2] libstdc++: Handle encodings in localized chrono formatting [PR109162]

Hi, Jonathan Wakely writes: > I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to > be done now due to the ABI impact on cris-elf. This one could wait for > stage 1. (HP, this one probably isn't of interest to you, but I don't > know how to tell git-send-email to only CC you

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

On 01/02/2024 07:19, Richard Biener wrote: On Wed, 31 Jan 2024, Andre Vieira (lists) wrote: The patch didn't come with a testcase so it's really hard to tell what goes wrong now and how it is fixed ... My bad! I had a testcase locally but never added it... However... now I look at it and

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

> From: Hans-Peter Nilsson > Date: Thu, 1 Feb 2024 17:16:47 +0100 > Not speaking for other platforms with default-packed layout > or where ABI structure layout alignment implies a change due > to PCC_BITFIELD_TYPE_MATTERS and the "unsigned long" > bitfield type. > > That last one may matter thou

[PATCH] gcc/configure: Re-introduce INSTALL_INFO

BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides BUILD_INFO="", which works when invoking

Re: [PATCH] aarch64: Fix ACLE SME streaming mode error in neon-sve-bridge

Richard Ball writes: > When using LTO, handling the pragma for sme before the pragma > for the neon-sve-bridge caused the following error on svset_neonq, > in the neon-sve-bridge.c test. > > error: ACLE function '0' can only be called when SME streaming mode is > enabled. > > Handling the pragmas

[PATCH] c++/modules: anon union member of as-base class [PR112580]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here when streaming in the fields of the as-base version of _Formatting_scanner we end up clobbering ANON_AGGR_TYPE_FIELD of the anonymous union type, since it turns out this type is shared between the original FIELD_DECL and th

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

On Thu, 1 Feb 2024 at 17:08, Hans-Peter Nilsson wrote: > > > From: Hans-Peter Nilsson > > Date: Thu, 1 Feb 2024 17:16:47 +0100 > > > Not speaking for other platforms with default-packed layout > > or where ABI structure layout alignment implies a change due > > to PCC_BITFIELD_TYPE_MATTERS and th

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote: > > On Feb 01 2024, Jonathan Wakely wrote: > > > This will result in an ABI change for targets that use 1-byte alignment > > for all integral types, e.g. cris-elf. > > Or 2-byte alignment as on m68k. Ah yes. In fact it's a change for everybody,

Re: [PATCH] AArch64: Remove AARCH64_EXTRA_TUNE_NO_LDP_STP_QREGS

Wilco Dijkstra writes: > (follow-on based on review comments on > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641913.html) > > > Remove the tune AARCH64_EXTRA_TUNE_NO_LDP_STP_QREGS since it is only > used by an old core and doesn't properly support -Os. SPECINT_2017 > shows that removi

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

On Thu, 1 Feb 2024, 17:23 Jonathan Wakely, wrote: > On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote: > > > > On Feb 01 2024, Jonathan Wakely wrote: > > > > > This will result in an ABI change for targets that use 1-byte alignment > > > for all integral types, e.g. cris-elf. > > > > Or 2-byte a

Re: [PATCH v4] AArch64: Cleanup memset expansion

Wilco Dijkstra writes: > Hi Richard, > >>> That tune is only used by an obsolete core. I ran the memcpy and memset >>> benchmarks from Optimized Routines on xgene-1 with and without LDP/STP. >>> There is no measurable penalty for using LDP/STP. I'm not sure why it was >>> ever added given it does

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

On Thu, 1 Feb 2024, Marek Polacek wrote: > On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote: > > > This will run the test only once with -std=c++11. We'll get better > > > coverage > > > with dropping the line above and using > > > > > > /* { dg-do compile { target { tail_call && { c

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

On 1/31/2024 11:29 PM, Li, Pan2 wrote: I can somehow reproduce the failures on commit id 23cd2961bd2ff63583f46e3499a07bd54491d45c, configurations as below. ./configure --prefix=${install_dir} \ --with-arch=rv64imafdcv \ --with-abi=lp64d \ --with-isa-spec=20191213 \ --with-sim=qemu make -j

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

On 1/31/2024 11:05 PM, juzhe.zh...@rivai.ai wrote: Sorry again. I just realized you have reverted your patches that's why I can pass the testing now. I checkout your latest patch commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Thu, Feb 01, 2024 at 02:32:33PM +, Alex Coplan wrote: > On 31/01/2024 15:53, Marek Polacek wrote: > > On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote: > > > Hi Marek, > > > > > > On 30/01/2024 13:15, Marek Polacek wrote: > > > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Me

[PATCH] x86-64: Find a scratch register for large model profiling

2 scratch registers, %r10 and %r11, are available at function entry for large model profiling. But %r10 may be used by stack realignment and we can't use %r10 in this case. Add x86_64_select_profile_regnum to find a scratch register for large model profiling and sorry if we can't find one. gcc/

Re: [PATCH] AArch64: memcpy/memset expansions should not emit LDP/STP [PR113618]

Wilco Dijkstra writes: > The new RTL introduced for LDP/STP results in regressions due to use of > UNSPEC. > Given the new LDP fusion pass is good at finding LDP opportunities, change the > memcpy, memmove and memset expansions to emit single vector loads/stores. > This fixes the regression and e

Re: [PATCH] x86-64: Find a scratch register for large model profiling

On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote: > --- a/gcc/config/i386/i386.cc > +++ b/gcc/config/i386/i386.cc > @@ -22749,6 +22749,31 @@ current_fentry_section (const char **name) >return true; > } > > +/* Return an unused caller-saved register at entry for profile. */ > + > +sta

[committed] hppa: Fix bug in atomic_storedi_1 pattern

Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- hppa: Fix bug in atomic_storedi_1 pattern The first alternative stores the floating-point status register in the destination. It should store zero. We need to copy %fr0 to another floating-point register to initialize it to zero.

[committed] xfail gnat.dg/trampoline3.adb scan-assembler-not check on hppa*-*-*

Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- xfail gnat.dg/trampoline3.adb scan-assembler-not check on hppa*-*-* We still require an executable stack for trampolines on hppa*-*-*. 2024-02-01 John David Anglin gcc/testsuite/ChangeLog: * gnat.dg/trampoline3.adb: xf

[committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests

Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- Set num_threads to 50 on 32-bit hppa in two libgomp loop tests We support a maximum of 50 threads on 32-bit hppa. 2024-02-01 John David Anglin libgomp/ChangeLog: * testsuite/libgomp.c++/loop-3.C: Set num_threads to 50

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

On Thu, 1 Feb 2024 at 17:22, Jonathan Wakely wrote: > > On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote: > > > > On Feb 01 2024, Jonathan Wakely wrote: > > > > > This will result in an ABI change for targets that use 1-byte alignment > > > for all integral types, e.g. cris-elf. > > > > Or 2-byt

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

> From: Jonathan Wakely > Date: Thu, 1 Feb 2024 19:24:49 + > I think I'd prefer to keep the reserved bits together, but a simpler > way to avoid 'unsigned long' making a difference for > PCC_BITFIELD_TYPE_MATTERS targets would be to use no more than 16 bits > but do: > >unsigned _M_r

Re: [PATCH] libgcc: Fix up i386/t-heap-trampoline [PR113403]

> On 1 Feb 2024, at 08:22, Jakub Jelinek wrote: > > On Wed, Jan 31, 2024 at 12:59:27PM +0100, Jakub Jelinek wrote: >> On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote: >>> --- a/libgcc/config/aarch64/t-heap-trampoline >>> +++ b/libgcc/config/aarch64/t-heap-trampoline >>> @@ -16,4 +1

Re: [PATCH] libgcc: Avoid warnings on __gcc_nested_func_ptr_created [PR113402]

> On 1 Feb 2024, at 08:51, Richard Biener wrote: > > On Thu, Feb 1, 2024 at 9:23 AM Jakub Jelinek wrote: >> >> On Wed, Jan 31, 2024 at 01:04:20PM +0100, Jakub Jelinek wrote: >>> On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote: * config/aarch64/heap-trampoline.c: Rename >>

Re: [PATCH] libgcc: Fix up i386/t-heap-trampoline [PR113403]

On Thu, Feb 01, 2024 at 07:58:29PM +, Iain Sandoe wrote: > Thanks, looks silly pasto that somehow managed to survive default testing > options. > > Tested x86_64-darwin (along with the warning suppression patch) and > tested for ftrampoline-impl={heap,stack} and {static,shared}-libgcc. Thanks

Re: [PATCH DejaGNU/GCC 0/1] Support per-test execution timeout factor

On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote: > > > Hmm. I think it would be more correct to emphasize that the > > > existing dg-timeout-factor affects both the tool execution *and* > > > the test execution, whereas your new dg-test-timeout-factor only > > > affects the test execution. (And

[committed] i386: Improve *cmp_doubleword splitter [PR113701]

The fix for PR70321 introduced a splitter that split a doubleword comparison into a pair of XORs followed by an IOR to set the (zero) flags register. To help the reload, splitter forced SUBREG pieces of double-word input values to a pseudo, but this regressed gcc.target/i386/pr82580.c int f0 (U x

Re: [RFC PATCH 1/1] nix: add a simple flake nix shell

Hi Eli, Yeah sorry I forgot to tag with -v2, so I am creating a -v3, after a while that I do not use email to send patches I get a little bit rusty. Thanks for your useful feedback, I am sending the v3 now. Cheers, Vincent. On Wed, Jan 31, 2024 at 11:19 PM Eli Schwartz wrote: > > On 1/31/

[RFC PATCH v3] nix: add a simple flake nix shell

This commit is specifically targeting enhancements in Nix support for GCC development. This initiative stems from the recognized need within our community for a more streamlined and efficient development process when using Nix. Please not that in this case the Nix tool is used to define what shoul

[PATCH] c++: -Wdangling-reference tweak to unbreak aarch64

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? aarch64-unknown-linux-gnu now bootstraps. -- >8 -- My recent -Wdangling-reference change to not warn on std::span-like classes unfortunately caused a new warning: extending reference_like_class_p also opens the door to new warnings sinc

RE: [PATCH]middle-end: check memory accesses in the destination block [PR113588].

> > > > If the above is correct then I think I understand what you're saying and > > will update the patch and do some Checks. > > Yes, I think that's what I wanted to say. > As discussed: Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu no issues. Also checked both wit

[PATCH] LoongArch: Fix an ODR violation

When bootstrapping GCC 14 --with-build-config=bootstrap-lto, an ODR violation is detected: ../../gcc/config/loongarch/loongarch-opts.cc:57: warning: 'abi_minimal_isa' violates the C++ One Definition Rule [-Wodr] 57 | abi_minimal_isa[N_ABI_BASE_TYPES][N_ABI_EXT_TYPES]; ../../gcc/con

Re: [PATCH 3/3] aarch64: Add SVE support for simd clones [PR 96342]

Andre Vieira writes: > This patch finalizes adding support for the generation of SVE simd clones when > no simdlen is provided, following the ABI rules where the widest data type > determines the minimum amount of elements in a length agnostic vector. > > gcc/ChangeLog: > > * config/aarch64/

  1   2   >