Re: [Patch, rs6000] Eliminate unnecessary byte swaps for block clear on P8 LE [PR113325]

On Fri, Jan 12, 2024 at 3:15 AM HAO CHEN GUI wrote: > > Hi Richard, >Thanks so much for your comments. > > > >> patch.diff > >> diff --git a/gcc/config/rs6000/rs6000-string.cc > >> b/gcc/config/rs6000/rs6000-string.cc > >> index 7f777666ba9..4c9b2cbeefc 100644 > >> --- a/gcc/config/rs6000/rs6

Re: [PATCH] Do not count unused scalar use when marking STMT_VINFO_LIVE_P [PR113091]

On Fri, Jan 12, 2024 at 7:15 AM Feng Xue OS wrote: > > Add a depth parameter to limit recursion of vec_slp_has_scalar_use. OK. > Feng > --- > > .../gcc.target/aarch64/bb-slp-pr113091.c | 22 ++ > gcc/tree-vect-slp.cc | 207 ++ > 2 files changed

[PATCH]middle-end: remove more usages of single_exit

Hi All, This replaces two more usages of single_exit that I had missed before. They both seem to happen when we re-use the ifcvt scalar loop for versioning. The condition in versioning is the same as the one for when we don't re-use the scalar loop. I hit these during an LTO enabled bootstrap no

Re: Re: [PATCH] RISC-V: Increase scalar_to_vec_cost from 1 to 3

Hi, Richard. I tried hard in RISC-V backend. I found to fix the case with -march=rv64gcv_zvl4096b can not be without vec_to_scalar count. Is there an approach that we can count vec_to_scalar cost without this piece code in middle-end ? /* ??? Enable for loop costing as well. */ i

[PATCH] middle-end/113344 - is_truth_type_for vs GENERIC tcc_comparison

On GENERIC tcc_comparison can have int type so restrict the PR113126 fix to vector types. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR middle-end/113344 * match.pd ((double)float CMP (double)float -> float CMP float): Perform result type check only for v

Re: [PATCH]middle-end: remove more usages of single_exit

On Fri, 12 Jan 2024, Tamar Christina wrote: > Hi All, > > This replaces two more usages of single_exit that I had missed before. > They both seem to happen when we re-use the ifcvt scalar loop for versioning. > > The condition in versioning is the same as the one for when we don't re-use > the

[PATCH V3] RISC-V: Adjust scalar_to_vec cost

1. Introduce vector regmove new tune info. 2. Adjust scalar_to_vec cost in add_stmt_cost. We will get optimal codegen after this patch with -march=rv64gcv_zvl256b: lui a5,%hi(a) li a4,19 sb a4,%lo(a)(a5) li a0,0 ret Tested on both RV32/R

Re: [PATCH] c++: reject packs on xobj params. [PR113307]

On Fri, Jan 12, 2024 at 07:40:19AM +, waffl3x wrote: > Bootstrapped and tested on x86_64-linux with no regressions. > > I'm still getting used to things so let me know if the change log > entries are excessive, thanks. > From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001 >

[PATCH] lower-bitint: Fix handling of casts on arches with abi_limb_mode != limb_mode

On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote: > So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge > BITINT_TYPEs to determine if it can be handled cheaply. > On x86_64 with limb_mode == abi_limb_mode (both DImode) that works fine, > if TYPE_SIZE is equal,

[PATCH] c: Avoid _BitInt indexes > sizetype in ARRAY_REFs [PR113315]

Hi! When build_array_ref doesn't use ARRAY_REF, it casts the index to sizetype already, performs POINTER_PLUS_EXPR and then dereferences. While when emitting ARRAY_REF, we try to keep index expression as is in whatever type it had, which is reasonable e.g. for signed or unsigned types narrower tha

[PATCH] lower-bitint: Fix up handling of uninitialized large/huge _BitInt call arguments [PR113316]

Hi! The code to assign large/huge _BitInt SSA_NAMEs to partitions intentionally ignores uninitialized SSA_NAMEs: /* Also ignore uninitialized uses. */ if (SSA_NAME_IS_DEFAULT_DEF (s) && (!SSA_NAME_VAR (s) || VAR_P (SSA_NAME_VAR (s continue; becaus

[PATCH] lower-bitint: Fix a typo in a condition [PR113323]

Hi! The following testcase revealed a typo in condition, as the comment says the intent is /* If lhs of stmt is large/huge _BitInt SSA_NAME not in m_names it means it will be handled in a loop or straight line code at the location of its (ultimate) immediate use, so f

[PATCH] sra: Punt for too large _BitInt accesses [PR113330]

Hi! This is the case I was talking about in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html and Zdenek kindly found a testcase for it. We can only create BITINT_TYPE with precision at most 65535, not 65536, so need to punt if we'd want to create it. Bootstrapped/regtested on x8

[committed] libstdc++: Fix incorrect PR number in comment

Tested x86_64-linux, pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/std/format (__format::_Arg_store): Fix PR number in comment. Simplify preprocessor code. --- libstdc++-v3/include/std/format | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

Re: [PATCH] lower-bitint: Fix handling of casts on arches with abi_limb_mode != limb_mode

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote: > > So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge > > BITINT_TYPEs to determine if it can be handled cheaply. > > On x86_64 with limb_mode == abi_limb_mode (both

Re: [PATCH] lower-bitint: Fix a typo in a condition [PR113323]

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > Hi! > > The following testcase revealed a typo in condition, as the comment > says the intent is >/* If lhs of stmt is large/huge _BitInt SSA_NAME not in m_names >it means it will be handled in a loop or straight line code >

Re: [PATCH] lower-bitint: Fix up handling of uninitialized large/huge _BitInt call arguments [PR113316]

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > Hi! > > The code to assign large/huge _BitInt SSA_NAMEs to partitions intentionally > ignores uninitialized SSA_NAMEs: > /* Also ignore uninitialized uses. */ > if (SSA_NAME_IS_DEFAULT_DEF (s) > && (!SSA_NAME_VAR (s) |

Re: [PATCH] sra: Punt for too large _BitInt accesses [PR113330]

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > Hi! > > This is the case I was talking about in > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html > and Zdenek kindly found a testcase for it. > We can only create BITINT_TYPE with precision at most 65535, not 65536, > so need to punt

[committed] libstdc++: Implement C++23 P1951R1 (Default Args for pair's Forwarding Ctor) [PR105505]

Tested aarch64-linux, pushed to trunk. -- >8 -- This was approved for C++23 at he June 2021 virtual meeting. This allows more efficient construction of std::pair members when {} is used as a constructor argument. The perfect forwarding constructor can be used, so that the member variables are co

Re: [PATCH] libstdc++: Fix std::runtime_format deviations from the spec [PR113320]

On Fri, 12 Jan 2024 at 06:53, Daniel Krügler wrote: > > Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely > : > > > > Tested x86_64-linux. Does this look better now? > > Yes, thank you. Thanks, pushed.

[committed] testsuite: Fix up preprocessor conditions in bitint-31.c test

Hi! Andre reported on IRC that this test has weird preprocessor conditions, obviously the intent was to test whether corresponding __*_MANT_DIG__ is equal to the expected value like earlier in the function definitions, but somehow I've ended up with a comma expression instead, which was always tru

Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

LGTM On Fri, Jan 12, 2024 at 7:37 AM Maciej W. Rozycki wrote: > > Verify that if-conversion succeeded through noce_try_store_flag_mask, as > per PR rtl-optimization/105314, tightening the test case and making it > explicit. > > gcc/testsuite/ > * gcc.target/riscv/pr105314.c: Scan

Re: [PATCH 1/2] RISC-V/testsuite: Widen coverage for pr105314.c

LGTM On Fri, Jan 12, 2024 at 7:36 AM Maciej W. Rozycki wrote: > > The optimization levels pr105314.c is iterated over are needlessly > overridden with "-O2", limiting the coverage of the test case to that > level, perhaps with additional options the original optimization level > has been supplied

Re: [PATCH] Fortran: annotations for DO CONCURRENT loops [PR113305]

On Wed, 10 Jan 2024 23:24:22 +0100 Harald Anlauf wrote: > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > index 82f388c05f8..88502c1e3f0 100644 > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -2926,6 +2926,10 @@ gfc_dt; > typedef struct gfc_forall_iterator > {

[PATCH] lower-bitint: Fix up handling of unsigned INTEGER_CSTs operands with lots of 1s in the upper bits [PR113334]

Hi! For INTEGER_CST operands, the code decides if it should emit the whole INTEGER_CST into memory, or if there are enough upper bits either all 0s or all 1s to warrant an optimization, where we use memory for lower limbs or even just an INTEGER_CST for least significant limb and fill in the rest

Re: [PATCH] lower-bitint: Fix up handling of unsigned INTEGER_CSTs operands with lots of 1s in the upper bits [PR113334]

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > Hi! > > For INTEGER_CST operands, the code decides if it should emit the whole > INTEGER_CST into memory, or if there are enough upper bits either all 0s > or all 1s to warrant an optimization, where we use memory for lower limbs > or even just an INTEG

[PATCH] varasm: Fix up process_pending_assemble_externals [PR113182]

Hi! John reported that on HP-UX we no longer emit needed external libcalls. The problem is that we didn't strip name encoding when looking up the identifiers in assemble_external_libcall and process_pending_assemble_externals, while assemble_name_resolve does that: const char *real_name = targe

Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

On Thu, Jan 11, 2024 at 3:37 PM Maciej W. Rozycki wrote: > > Verify that if-conversion succeeded through noce_try_store_flag_mask, as > per PR rtl-optimization/105314, tightening the test case and making it > explicit. > > gcc/testsuite/ > * gcc.target/riscv/pr105314.c: Scan the RT

Re: [PATCH V3] RISC-V: Adjust scalar_to_vec cost

> Tested on both RV32/RV64 no regression, Ok for trunk ? Yes, thanks! Btw out of curiosity, did you see why we actually fail to optimize away the VLA loop? We should open a bug for that I suppose. Regards Robin

Re: [PATCH] Add support for function attributes and variable attributes

> It sounds like the patch you have locally is ready, but it has some > nontrivial changes compared to the last version you posted to the list. > Please post your latest version to the list. Sure! This patch adds the support for attributes on functions and variables. It does so by adding the foll

Re: [PATCH V3] RISC-V: Adjust scalar_to_vec cost

VLA is a known issue for a long time.GCC doesn't have too much cse optimization forVLA vectors. It should be a big work to investigate what's going on.I think most cse optimization for precomputed result are vls loop. So I think as long as we can do a good job on cost model which pick appropriate v

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Thu, 11 Jan 2024 at 22:17, Jonathan Wakely wrote: > > I'd like to commit this to trunk for GCC 14. Please take a look. > > -- >8 -- > > This is the last part of PR libstdc++/108822 implementing P2255R2, which > makes it ill-formed to create a std::tuple that would bind a reference > to a tempora

Ping [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.) On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote: > Tested mmix-knuth-mmixware (where all torture-variants of > gcc.dg/torture/inline-mem-cpy-1.c now pass) and native > x86_64-pc-linux-gnu. Also stepped through the test for native, > w/

Re: [PATCH] rs6000: New pass for replacement of adjacent lxv with lxvp.

Hi Ajit, I have taken a quick look at the patch and my comments are inlined: On 09/01/24 4:44 pm, Ajit Agarwal wrote: > Hello All: > > This pass is registered before ira rtl pass. > Bootstrapped and regtested for powerpc64-linux-gnu. > > No regressions for spec 2017 benchmarks and improvements f

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

On Jan 12, 2024, "Kewen.Lin" wrote: >>> By checking PR112917, IMHO we should keep this unbiasing >>> guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 && >>> TARGET_STACK_BIAS), similar to some existing code special >>> treating SPARC stack bias. >> >> I'm afraid this change will most certa

Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

在 2024-01-12星期五的 09:46 +0800，chenglulu写道： > > I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS: > > we need a target hook to tell the generic code > > UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll > > see millions lines of messages like > > > > ..

Re: [PATCH] varasm: Fix up process_pending_assemble_externals [PR113182]

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > Hi! > > John reported that on HP-UX we no longer emit needed external libcalls. > > The problem is that we didn't strip name encoding when looking up > the identifiers in assemble_external_libcall and > process_pending_assemble_externals, while > assem

[PATCHv3] aarch64/expr: Use ccmp when the outer expression is used twice [PR100942]

Andrew Pinski writes: > Ccmp is not used if the result of the and/ior is used by both > a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation > here by using ccmp in this case. > Two changes is required, first we need to allow the outer statement's > result be used more than once. >

[PATCH 1/2] aarch64: Use a separate group for SME builtins [PR112989]

The PR shows that we were registering the same overloaded SVE builtins twice. This was supposed to be prevented by function_builder::add_overloaded_function, which uses a map to detect whether a function of the same name has already been registered. add_overloaded_function then had some asserts t

[PATCH 2/2] aarch64: Use a global map to detect duplicated overloads [PR112989]

As explained in the covering note to the previous patch, the fact that aarch64-sve-* is now used for multiple header files means that function_builder::add_overloaded_function now needs to use a global map to detect duplicated overload functions, instead of the member variable that it used previous

Re: [patch,avr,applied] PR target/112952 Fix attribute "io" et al. handling.

Am 12.01.24 um 04:37 schrieb Jan-Benedict Glaw: On Thu, 2024-01-04 17:28:02 +0100, Georg-Johann Lay wrote: This fixes the avr-specific attributes io, io_low and address, that are all basically the same except that io and io_low imply assertions on allowed addressing modes. --- a/gcc/confi

[pushed] aarch64: Rework uxtl->zip optimisation [PR113196]

g:f26f92b534f9 implemented unsigned extensions using ZIPs rather than UXTL{,2}, since the former has a higher throughput than the latter on amny cores. The optimisation worked by lowering directly to ZIP during expand, so that the zero input could be hoisted and shared. However, changing to ZIP m

[PATCH] c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal

Hi! The following patch attempts to implement what apparently clang++ implemented for explicit object member function mangling, but nobody actually proposed in patch form in https://github.com/itanium-cxx-abi/cxx-abi/issues/148 Ok for trunk if it passes full bootstrap/regtest? So far just tested

[patch,avr,applied] Fix PR107201 -nodevicelib not working for all devices.

Since the advent of devices AVR*, the spec pattern mmcu=avr* does no more work to discriminate between devices and cores like avr51. This means -nodevicelib no more works for AVR* devices because that option is removed for mmcu=avr* (which were only cores in the old days). Instead of that patter

GCC 14.0.1 Status Report (2024-01-12), Stage 4 in effect now

Status == The GCC development branch which will become GCC 14 is now in regression and documentation fixes only mode (Stage 4). Please concentrate now on fixing regressions from GCC 13 and earlier. GCC 14.1 will be released when we reach the milestone of zero P1 regressions (note not all reg

Re: [PATCH] Add support for function attributes and variable attributes

Just realized that you were asking for the patch I forgot to join... Here it is. Le ven. 12 janv. 2024 à 11:09, Guillaume Gomez a écrit : > > > It sounds like the patch you have locally is ready, but it has some > > nontrivial changes compared to the last version you posted to the list. > > Plea

Re: [PATCH] c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal

On 1/12/24 07:45, Jakub Jelinek wrote: Hi! The following patch attempts to implement what apparently clang++ implemented for explicit object member function mangling, but nobody actually proposed in patch form in https://github.com/itanium-cxx-abi/cxx-abi/issues/148 Ok for trunk if it passes fu

Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

On Fri, 12 Jan 2024, Andrew Pinski wrote: > > Verify that if-conversion succeeded through noce_try_store_flag_mask, as > > per PR rtl-optimization/105314, tightening the test case and making it > > explicit. > > > > gcc/testsuite/ > > * gcc.target/riscv/pr105314.c: Scan the RTL "ce

GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'

Hi! OK to push the attached "GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'"? ("The relevant test cases are all-PASS with just [two] exceptions, to be looked into individually, later on." I'm not currently planning to look into that.) Grüße Thomas - Si

[pushed] Darwin, powerpc: Fix bootstrap.

Tested on powerpc-darwin9, pushed to trunk, thanks, Iain --- 8< --- Recent changes to the member names of the diagnostics class missed one case in the Darwin PowerPC host code. Fixed thus. gcc/ChangeLog: * config/rs6000/host-darwin.cc (segv_handler): Use the revised diagnostics

Re: [PATCH RFC] c++/modules: __class_type_info and modules

On 12/23/23 14:46, Nathan Sidwell wrote: On 12/18/23 17:10, Jason Merrill wrote: On 12/18/23 16:57, Nathan Sidwell wrote: On 12/18/23 16:31, Jason Merrill wrote: Tested x86_64-pc-linux-gnu.  Does this make sense?  Did you have another theory about how to merge these? Why isn't push_abi_name

Re: [pushed] c++: corresponding object parms [PR113191]

On 1/11/24 17:01, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- As discussed, our handling of corresponding object parameters needed to handle the using-declaration case better. And I took the opportunity to share code between the add_method and cand_parms_match

[pushed] Objective-C, Darwin: Fix a regression in handling bad receivers.

Tested on i686 and powerpc darwin, and a cross from x86-64 darwin to powerpc, pushed to trunk, thanks, Iain --- 8< --- This is seen on 32b targets with a 64b multilib, and is an ICE when the build has checking enabled. The fix is to exit the routine early if the sender or receiver are already er

[PATCH] tree-optimization/109893 - allow more backwards jump threading

Currently we scale the number of stmts allowed for forward jump threading to limit those for backwards jump threading by applying a factor of two to the counted stmts. That doesn't allow fine-grained adjustments, like by a single stmt as needed for PR109893. The following changes the factor to be

Re: [pushed][PR112918][LRA]: Fixing IRA ICE on m68k

Vladimir Makarov 于2024年1月11日周四 22:35写道： > > The following patch fixes > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 > > The patch was successfully bootstrapped and tested on x86_64, aarch64, > ppc64le This patch causes some ICE on MIPS: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11335

Re: [PATCH] c: Avoid _BitInt indexes > sizetype in ARRAY_REFs [PR113315]

On Fri, 12 Jan 2024, Jakub Jelinek wrote: > Hi! > > When build_array_ref doesn't use ARRAY_REF, it casts the index to sizetype > already, performs POINTER_PLUS_EXPR and then dereferences. > While when emitting ARRAY_REF, we try to keep index expression as is in > whatever type it had, which is re

HELP: Questions on unshare_expr

Hi, I have some questions on using the utility routine “unshare_expr”: From my understanding, there should be NO shared nodes in a GENERIC function. Otherwise, gimplication might fail. Therefore, when we insert new tree nodes manually into the GENERIC function, we should Make sure there is

Re: HELP: Questions on unshare_expr

> Am 12.01.2024 um 16:55 schrieb Qing Zhao : > > Hi, > > I have some questions on using the utility routine “unshare_expr”: > > From my understanding, there should be NO shared nodes in a GENERIC function. > Otherwise, gimplication might fail. There is sharing and this is why we unshare eve

Re: [PATCH v3 00/12] [GCC] arm: vld1q vst1 vst1q vst1 intrinsics

On 02/01/2024 09:23, ezra.sito...@arm.com wrote: > From: Ezra Sitorus > > Add vld1q, vst1, vst1q and vst1 intrinsics to arm port. > > Ezra Sitorus (12): > [GCC] arm: vld1q_types_x2 ACLE intrinsics > [GCC] arm: vld1q_types_x3 ACLE intrinsics > [GCC] arm: vld1q_types_x4 ACLE intrinsics > [

Re: [PATCH RFC] c++/modules: __class_type_info and modules

On 1/12/24 09:09, Jason Merrill wrote: On 12/23/23 14:46, Nathan Sidwell wrote: On 12/18/23 17:10, Jason Merrill wrote: On 12/18/23 16:57, Nathan Sidwell wrote: On 12/18/23 16:31, Jason Merrill wrote: Tested x86_64-pc-linux-gnu.  Does this make sense?  Did you have another theory about how t

Re: HELP: Questions on unshare_expr

Thanks a lot for the reply. > On Jan 12, 2024, at 11:28 AM, Richard Biener > wrote: > > > >> Am 12.01.2024 um 16:55 schrieb Qing Zhao : >> >> Hi, >> >> I have some questions on using the utility routine “unshare_expr”: >> >> From my understanding, there should be NO shared nodes in a GE

[patch,avr,applied] Fix documentation for attribute "address".

avr attribute "address" only supports exactly one argument, fixed thusly. Johann -- AVR: Documentation: Attribute address has exactly one argument. gcc/ * doc/extend.texi (AVR Variable Attributes) [address]: Remove documentation for a version without argument, which is not supp

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Thu, 11 Jan 2024, Jonathan Wakely wrote: > I'd like to commit this to trunk for GCC 14. Please take a look. > > -- >8 -- > > This is the last part of PR libstdc++/108822 implementing P2255R2, which > makes it ill-formed to create a std::tuple that would bind a reference > to a temporary. > >

Re: Ping [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

On Jan 12, 2024, at 2:52 AM, Hans-Peter Nilsson wrote: > > Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.) > > On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote: > >> Tested mmix-knuth-mmixware (where all torture-variants of >> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native >

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote: > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > I'd like to commit this to trunk for GCC 14. Please take a look. > > > > -- >8 -- > > > > This is the last part of PR libstdc++/108822 implementing P2255R2, which > > makes it ill-formed to cre

[patch,avr,applied] Add link to sample ld-script in avr-gcc wiki.

This links an example from the avr-gcc wiki that shows how to set up a linker script for the __flashN avr address spaces in section AVR Named Address Spaces of the GCC user manual. Johann -- AVR: Documentation: Web-Link an example ld-Script for Address-Space __flashN. gcc/ * doc/exte

[PATCH V3 0/4] RISC-V: Associate typed insns to dfa reservation

Updates all tune insn reservation pipelines to cover all types defined by define_attr "type" in riscv.md. Creates new vector insn reservation pipelines in new file generic-vector-ooo.md which has separate automaton vector_ooo where all reservations are mapped to. This allows all tunes to share a c

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

This patch adds non-vector related insn reservations and updates/creates new insn reservations so all non-vector typed instructions have a reservation. gcc/ChangeLog: * config/riscv/generic-ooo.md (generic_ooo_sfb_alu): Add reservation (generic_ooo_branch): ditto * config/

[PATCH V3 2/4] RISC-V: Add vector related pipelines

Creates new generic vector pipeline file common to all cpu tunes. Moves all vector related pipelines from generic-ooo to generic-vector-ooo. Creates new vector crypto related insn reservations. Add temporary attribute for making changes to the vector cost model gcc/ChangeLog: * config/ris

[PATCH V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation

Enables assert that every typed instruction is associated with a dfa reservation gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert Signed-off-by: Edwin Lu --- V2: - No changes V3: - No changes --- gcc/config/riscv/riscv.cc | 6 -- 1 file changed, 4

[PATCH V3 3/4] RISC-V: Use default cost model for insn scheduling

Use default cost model scheduling on these test cases. All these tests introduce scan dump failures with -mtune generic-ooo. Since the vector cost models are the same across all three tunes, some of the tests in PR113249 will be fixed with this patch series. 39 additional unique testsuite failures

Re: [PATCH] libstdc++: Make PSTL algorithms accept C++20 iterators [PR110512]

On Thu, 11 Jan 2024, Jonathan Wakely wrote: > Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only. > > Reviews requested. > > -- >8 -- > > This is a step towards implementing the C++23 change P2408R5, "Ranges > iterators as inputs to non-Ranges algorithms". C++20 random access > iterato

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Fri, 12 Jan 2024, Jonathan Wakely wrote: > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote: > > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > > > I'd like to commit this to trunk for GCC 14. Please take a look. > > > > > > -- >8 -- > > > > > > This is the last part of PR libstdc++/10

[PATCH, v2] Fortran: annotations for DO CONCURRENT loops [PR113305]

Hi Bernhard, On 1/12/24 10:44, Bernhard Reutner-Fischer wrote: On Wed, 10 Jan 2024 23:24:22 +0100 Harald Anlauf wrote: diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index 82f388c05f8..88502c1e3f0 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2926,6 +2926,

[PATCH 1/2] libstdc++: Use C++23 deducing this in std::bind_front

This simplifies the operator() of _Bind_front using C++23 deducing this, allowing us to condense multiple nearly identical operator() overloads into one. In passing I think we can remove _Bind_front's defaulted special member declarations and just let the compiler implicitly generate them for us.

[PATCH 2/2] libstdc++: Implement C++23 std::bind_pack from P2387R3 [PR108827]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? PR libstdc++/108827 PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/bits/version.def (bind_back): Define. * include/bits/version.h: Regenerate. * include/std/functional (_Bind_back): Define

RE: [PATCHv3] aarch64/expr: Use ccmp when the outer expression is used twice [PR100942]

> -Original Message- > From: Richard Sandiford > Sent: Friday, January 12, 2024 4:26 AM > To: Andrew Pinski (QUIC) > Cc: gcc-patches@gcc.gnu.org > Subject: [PATCHv3] aarch64/expr: Use ccmp when the outer expression is > used twice [PR100942] > > Andrew Pinski writes: > > Ccmp is not use

Re: [PATCH 1/2] libstdc++: Use C++23 deducing this in std::bind_front

On Fri, 12 Jan 2024 at 20:09, Patrick Palka wrote: > > This simplifies the operator() of _Bind_front using C++23 deducing > this, allowing us to condense multiple nearly identical operator() > overloads into one. > > In passing I think we can remove _Bind_front's defaulted special member > declara

Re: [PATCH 2/2] libstdc++: Implement C++23 std::bind_pack from P2387R3 [PR108827]

On Fri, 12 Jan 2024 at 20:10, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK > > PR libstdc++/108827 > PR libstdc++/111327 > > libstdc++-v3/ChangeLog: > > * include/bits/version.def (bind_back): Define. > * include/bits/ve

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote: > > On Fri, 12 Jan 2024, Jonathan Wakely wrote: > > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote: > > > > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > > > > > I'd like to commit this to trunk for GCC 14. Please take a look. > > >

Re: [PATCH v2 1/2] Implement ASM_DECLARE_FUNCTION_NAME using ASM_OUTPUT_FUNCTION_LABEL

On Tue, 2024-01-02 20:41:37 +0100, Ilya Leoshkevich wrote: > diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc > index ac566efcf19..92d00bf922f 100644 > --- a/gcc/config/ia64/ia64.cc > +++ b/gcc/config/ia64/ia64.cc > @@ -3886,8 +3886,7 @@ ia64_expand_prologue (void) > /* Output the t

[WIP] libstdc++: Implement C++26 std::text_encoding [PR113318]

Here's a partial patch for PR libstdc++/113318 to implement another C++26 feature: https://wg21.link/p1885r12 I'm writing the rest of the tests, but thought I would post it now for comments on the general approach. The text_encoding class is basically just a pointer to an {ID,name} pair in the st

[PATCH] libstdc++: Update tzdata to 2023d

It would be good to update the bundled tzdata for GCC 14.1 and 13.3 Tested x86_64-linux. Any objections? -- >8 -- Import the new 2023d tzdata.zi file. libstdc++-v3/ChangeLog: * src/c++20/tzdata.zi: Import new file from 2023d release. --- libstdc++-v3/src/c++20/tzdata.zi | 23

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote: > > On Fri, 12 Jan 2024, Jonathan Wakely wrote: > > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote: > > > > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > > > > > I'd like to commit this to trunk for GCC 14. Please take a look. > > >

Re: [PATCH] libstdc++: Make PSTL algorithms accept C++20 iterators [PR110512]

On Fri, 12 Jan 2024 at 18:11, Patrick Palka wrote: > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only. > > > > Reviews requested. > > > > -- >8 -- > > > > This is a step towards implementing the C++23 change P2408R5, "Ranges > > iterat

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

On Fri, 12 Jan 2024, Jonathan Wakely wrote: > On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote: > > > > On Fri, 12 Jan 2024, Jonathan Wakely wrote: > > > > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote: > > > > > > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > > > > > > > I'd like

[r14-7199 Regression] FAIL: gcc.dg/vect/vect-early-break_100-pr113287.c (test for excess errors) on Linux/x86_64

On Linux/x86_64, d14ef0987de2f6f2dac64f4f0f068b929078a01d is the first bad commit commit d14ef0987de2f6f2dac64f4f0f068b929078a01d Author: Tamar Christina Date: Fri Jan 12 15:27:45 2024 + testsuite: Make bitint early vect test more accurate caused FAIL: gcc.dg/vect/vect-early-break_10

[PATCH] testsuite: Fix fallout of turning warnings into errors on 32-bit Arm

Since commits 2c3db94d9fd ("c: Turn int-conversion warnings into permerrors") and 55e94561e97e ("c: Turn -Wimplicit-function-declaration into a permerror") these tests fail with errors such as: FAIL: gcc.target/arm/pr59858.c (test for excess errors) FAIL: gcc.target/arm/pr65647.c (test for exc

[PATCH] RISC-V: Adjust loop len by costing 1 when NITER < VF [GCC 14 regression]

This patch fixes the regression between GCC 13.2.0 and trunk GCC (GCC-14) GCC 13.2.0: lui a5,%hi(a) li a4,19 sb a4,%lo(a)(a5) li a0,0 ret Trunk GCC: vsetvli a5,zero,e8,mf2,ta,ma li a4,-32768 vid.v v1

[COMMITTED] Add a few testcases for fix missed optimization regressions

Adds a few new testcases for some missed optimization regressions. The analysis on how each should be optimized is in the testcases themselves (and in the bug report). Committed as obvious after running the testsuite to make sure they pass. PR tree-optimization/107823 PR tree-opti

[PATCH] LoongArch: Assign the '/u' attribute to the mem to which the global offset table belongs.

gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_split_symbol): Assign the '/u' attribute to the mem. gcc/testsuite/ChangeLog: * g++.target/loongarch/got-load.C: New test. --- gcc/config/loongarch/loongarch.cc | 5 + gcc/testsuite/g++.target/loo

Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

在 2024/1/12 下午7:42, Xi Ruoyao 写道: 在 2024-01-12星期五的 09:46 +0800，chenglulu写道： I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS: we need a target hook to tell the generic code UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll see millions lines of me

[PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

gcc/testsuite/ChangeLog: * gcc.dg/pr104992.c: Added additional "-mlsx" compilation options. * gcc.dg/signbit-2.c: Dito. * gcc.dg/tree-ssa/scev-16.c: Dito. * gfortran.dg/graphite/vect-pr40979.f90: Dito. * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. --- g

[PATCH v2] LoongArch: testsuite:Fix fail in gen-vect-{2,25}.c file.

1.Added dg-do compile on LoongArch. When binutils does not support vector instruction sets, an error occurs because the assembler does not recognize vector instructions. 2.Added "-mlsx" option for vectorization on LoongArch. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/gen-vect-2.c: Add