[PATCH] c, libcpp: Partially implement C2Y N3353 paper [PR117028]

Hi! The following patch partially implements the N3353 paper. In particular, it adds support for the delimited escape sequences (\u{123}, \x{123}, \o{123}) which were added already for C++23, all I had to do is split the delimited escape sequence guarding from named universal character escape sequ

[PATCH][wwwdoc] Mention O2 vectorization enhancement.

--- htdocs/gcc-15/changes.html | 10 ++ 1 file changed, 10 insertions(+) diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index 6dc46a52..8a238256 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@ -36,6 +36,16 @@ a work-in-progress. General

[PATCH] Introduce TARGET_FMV_ATTR_SEPARATOR

Some architectures may use ',' in the attribute string, but it is not used as the separator for different targets. To avoid conflict, we introduce a new macro TARGET_FMV_ATTR_SEPARATOR to separate different clones. As an example, according to RISC-V C-API Specification [1], RISC-V allows ',' in th

[PATCH] Support andn_optab for x86

Hi all, This patch is to add andn_optab for x86. Bootstrapped and regtested on x86-64-linux-pc, OK for trunk? Regards, Lili. Add new andn pattern to match the new optab added by r15-1890-gf379596e0ba99d. Only enable 64bit, 128bit and 256bit vector ANDN, X86-64 has mask mov instruction when avx

[PATCH] c++: checking ICE w/ lambda targ inside constexpr if [PR117054]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here we're tripping over the assert in extract_locals_r which enforces that an extra-args tree appearing inside another extra-args tree doesn't actually have extra args. This invariant no longer always holds

[PATCH] c++: unifying lvalue vs rvalue (non-forwarding) ref [PR116710]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When unifying two (non-forwarding) reference types, unify immediately recurses into the reference type without first comparing rvalueness. (Note that at this point forwarding references have already been coll

[PATCH 2/2] c++: constrained auto NTTP vs associated constraints

According to [temp.param]/11, the constraint on an auto NTTP is an associated constraint and so should be checked as part of satisfaction of the overall associated constraints rather than checked individually during coerion/deduction. In order to implement this we mainly need to make handling of c

[PATCH 1/2] c++: some further concepts cleanups

This patch further cleans up the concepts code following the removal of Concepts TS support: * concept-ids are now the only kind of "concept check", so we can simplify some code accordingly. In particular resolve_concept_check seems like a no-op and can be removed. * In turn, deduce_c

[PATCH 1/2] c++: some further concepts cleanups

This patch further cleans up the concepts code following the removal of Concepts TS support: * concept-ids are now the only kind of "concept check", so we can simplify some code accordingly. In particular resolve_concept_check seems like a no-op and can be removed. * In turn, deduce_c

[PATCH 2/2] [x86] Canonicalize (vec_merge (fma: op2 op1 op3) (match_dup 1)) mask) to (vec_merge (fma: op1 op2 op3) (match_dup 1)) mask)

For masked FMA, there're 2 forms of RTL representation 1) (vec_merge (fma: op2 op1 op3) op1) mask) 2) (vec_merge (fma: op1 op2 op3) op1) mask) It's because op1 op2 are communatative in RTL(the second op1 is written as (match_dup 1)) we once tried to replace (match_dup 1) with (match_operand:VFH_AV

[PATCH 1/2] [Middle-end] Canonicalize (vec_merge (fma op2 op1 op3) op1 mask) to (vec_merge (fma op1 op2 op3) op1 mask).

For x86 masked fma, there're 2 rtl representations 1) (vec_merge (fma op2 op1 op3) op1 mask) 2) (vec_merge (fma op1 op2 op3) op1 mask). 5894(define_insn "_fmadd__mask" 5895 [(set (match_operand:VFH_AVX512VL 0 "register_operand" "=v,v") 5896(vec_merge:VFH_AVX512VL 5897 (fma:VF

[PATCH 0/2] Canonicalize (vec_merge (fma op1 op2 op3) op1 mask) to (vec_merge (fma op1 op2 op3) op1 mask)

For x86 masked fma, there're 2 rtl representations 1) (vec_merge (fma op2 op1 op3) op1 mask) 2) (vec_merge (fma op1 op2 op3) op1 mask). 5894(define_insn "_fmadd__mask" 5895 [(set (match_operand:VFH_AVX512VL 0 "register_operand" "=v,v") 5896(vec_merge:VFH_AVX512VL 5897 (fma:

[PATCH] dce: Remove FIXME that has not been true for years

This FIXME: FIXME: Aggressive mode before PRE doesn't work currently because the dominance info is not invalidated after DCE1. Has not been true since at least r0-104723-g5ac60b564faa85 which added a call to calculate_dominance_info. Plus we run agressive mode before PRE since r0-8916

RE: [PATCH] RISC-V: Fix UNRESOLVED testcases for SAT alu vector mode

Thanks Kito. Just notice these some silly mistakes this morning, ;)! Pan -Original Message- From: Kito Cheng Sent: Tuesday, October 15, 2024 9:45 AM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; rdapp@gmail.com Subject: Re: [PATCH] RISC-V:

Re: [PATCH] RISC-V: Fix UNRESOLVED testcases for SAT alu vector mode

LGTM, I just saw that yesterday as well, fortunately, I haven't started fixing yet. :P On Tue, Oct 15, 2024 at 9:43 AM wrote: > > From: Pan Li > > Some saturation related alu testcases missed additional option > for expand check, which result in some UNRESOLVED issues. This > patch would like

[PATCH] RISC-V: Fix UNRESOLVED testcases for SAT alu vector mode

From: Pan Li Some saturation related alu testcases missed additional option for expand check, which result in some UNRESOLVED issues. This patch would like to fix it by adding the option back as other testcases. The below test are passed for this patch. * The rv64gcv fully regression test. It

[PATCH] Android: Fix build for Android

gcc/ * config.gcc: fix target aarch64-linux-android, arm-linux-androideabi, i686-linux-android, x86_64-linux-android * config/linux-android.h: fix SPEC based on aarch64-linux-android-clang * config/aarch64/aarch64-elf.h: Add Macro DEFAULT_ASM_SPEC * config/aa

Re: [PATCH] c++: Fix mangling of otherwise unattached class-scope lambdas [PR116568]

On Fri, Oct 11, 2024 at 10:37:11AM -0400, Jason Merrill wrote: > On 9/5/24 11:02 AM, Nathaniel Shead wrote: > > Bootstrapped and regtested (so far just dg.exp) on x86_64-pc-linux-gnu, > > OK for trunk if full regtest passes? Or would it be better to try to > > implement all the rules mentioned in

[PATCH 1/2] libgcc: Use -Os/-Oz from CC or CFLAGS

Override other optimization settings with any -Os or -Oz found in CC or CFLAGS. libgcc/ChangeLog: * Makefile.in: Use -Os or -Oz from CC or CFLAGS Signed-off-by: Keith Packard --- libgcc/Makefile.in | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/libgcc/Ma

[PATCH 2/2] gcc: Add --enable-multilib-space option

This option adds a per-multilib variant that specifies -Os instead of the default. With this, all multilib libraries will be built with -Os as well as -O2; the appropriate one selected automatically at link time based upon the optimization level selected. This could be done in the target configura

[PATCH 0/2] Automate creation of -O2 and -Os multilib variants

When building toolchains for embedded development, some projects will want to optimize for speed while others are much more concerned about overall code size. We can do this using the existing GCC multilib infrastructure, adding suitable speed and size variants as another dimension of the multilib

[PATCH] Match: Remove dup match pattern for signed_integer_sat_sub [PR117141]

From: Pan Li This patch would like to fix the warning as below: /home/slyfox/dev/git/gcc/gcc/match.pd:3424:3 warning: duplicate pattern (cond^ (ne (imagpart (IFN_SUB_OVERFLOW:c@2 @0 @1)) integer_zerop) ^ /home/slyfox/dev/git/gcc/gcc/match.pd:3397:3 warning: previous pattern defined here (con

[pushed: r15-4343] diagnostics: fix overload of emit_diagnostic [PR117109]

I accidentally broke "make gcc.pot" in r15-4081 by adding a member function diagnostic_context::emit_diagnostic with a gmsgid in a different position to the existing emit_diagnostic functions, which exgettext's parser can't handle. Fixed thusly. Successfully bootstrapped & regrtested on x86_64-pc

[PATCH] Add 'cobol' to Makefile.def, take 2

Consequent to advice, I'm preparing the Cobol front-end patches as a small number of hopefully meaningful patches covering many files. 1. meta files used by autotools etc. 2. gcc/cobol/*.h 3. gcc/cobol/*.{y,l,cc} 4. libgcobol 5. documentation 6. tests The patch below is step #1. It compr

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

On 14 October 2024 10:23:56 CEST, Thomas Schwinge wrote: >Hi Tobias! > >On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: >> Now pushed as r15-4298-g3269a722b7a036. > >> Tobias Burnus wrote: >>> Anyone feeling like reviewing this patch? > >Yes. But please allow for more than 1 1/2 work days. >

Re: [PATCH 0/5] Provide better definitions of NULL

Hi Jason, You've recently touched code about C++ modules. Do you have any idea of why my changes may be introducing regressions in the tests? Have a lovely night! Alex On Sun, Oct 13, 2024 at 11:56:55PM GMT, Alejandro Colomar wrote: > Hi Joseph, > > On Fri, Oct 11, 2024 at 01:44:36PM GMT, Alej

Re: [pushed] c++: address deduction and concepts [CWG2918]

On Mon, 14 Oct 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > CWG2918 changes deduction from an overload set for the case where multiple > candidates succeed and have the same type; previously this made the overload > set a non-deduced context, now i

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

Sam James writes: > Andre Vehreschild writes: > >> Hi all, >> >> please note, that I don't know this bisecting very well, so this may very >> well >> be a wrong blame. During latest regression testing of the Fortran suite I got >> typebound_operator_7.f03 failing with: >> >> typebound_operator_

Re: [PATCH 5/5] passes: Remove limit on the number of params

On Mon, Oct 14, 2024 at 10:17 AM Andrew Pinski wrote: > > On Mon, Oct 14, 2024 at 6:10 AM Richard Biener > wrote: > > > > On Mon, Oct 14, 2024 at 4:32 AM Andrew Pinski > > wrote: > > > > > > Having a limit of 2 params for NEXT_PASS was just done because I didn't > > > think there was > > > a w

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

Andre Vehreschild writes: > Hi all, > > please note, that I don't know this bisecting very well, so this may very well > be a wrong blame. During latest regression testing of the Fortran suite I got > typebound_operator_7.f03 failing with: > > typebound_operator_7.f03:94:25: > >94 | u = (u*

Re: [PATCH] expr: Don't clear whole unions [PR116416]

On 10/7/24 2:45 PM, Marek Polacek wrote: On Wed, Oct 02, 2024 at 05:52:13PM -0400, Jason Merrill wrote: On 10/2/24 3:20 PM, Marek Polacek wrote: On Sat, Sep 28, 2024 at 08:39:12AM +0200, Jakub Jelinek wrote: On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote: So, I think we should

[pushed] c++: address deduction and concepts [CWG2918]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- CWG2918 changes deduction from an overload set for the case where multiple candidates succeed and have the same type; previously this made the overload set a non-deduced context, now it succeeds since the result is consistent between the can

Re: [PATCH 1/3]AArch64: update testsuite to account for new zero moves

Tamar Christina writes: > Hi All, > > The patch series will adjust how zeros are created. In principal it doesn't > matter the exact lane size a zero gets created on but this makes the tests a > bit fragile. > > This preparation patch will update the testsuite to accept multiple variants > of way

Re: [PATCH 3/4]AArch64: enable zero-extends using TBLs for Adv. SIMD

Tamar Christina writes: > Hi All, > > In this patch series I'm adding support for zero extending using permutes > instead of requiring multi-step decomposition. > > This codegen has the benefit of needing fewer instructions and having much > higher throughput than uxtl. We previously replaced pai

Re: [PATCH] libstdc++: Implement LWG 3564 for ranges::transform_view

On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > The _Iterator type returned by begin() const uses const F& to > transform the elements, so it should use const F& to determine the > iterator's value_type and iterator_category as well. > > This was accepted int

RE: [PATCH 1/4]middle-end: support multi-step zero-extends using VEC_PERM_EXPR

> -Original Message- > From: Richard Sandiford > Sent: Monday, October 14, 2024 7:34 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de > Subject: Re: [PATCH 1/4]middle-end: support multi-step zero-extends using > VEC_PERM_EXPR > > Tamar Christina writes: > >

Re: [PATCH 3/3]AArch64: use movi d0, #0 to clear SVE registers instead of mov z0.d, #0

Tamar Christina writes: > Hi All, > > This patch changes SVE to use Adv. SIMD fmov 0 to clear SVE registers when not s/fmov/movi/, here and below. OK with that change, thanks. Richard > in SVE streaming mode. As the Neoverse Software Optimization guides indicate > SVE mov #0 is not a zero cos

Re: [PATCH 1/4]middle-end: support multi-step zero-extends using VEC_PERM_EXPR

Tamar Christina writes: > Hi All, > > This patch series adds support for a target to do a direct convertion for zero > extends using permutes. > > To do this it uses a target hook use_permute_for_promotio which must be > implemented by targets. This hook is used to indicate: > > 1. can a target

Re: [PATCH v2 00/36] arm: [MVE intrinsics] Re-implement more intrinsics

On 04/09/2024 14:26, Christophe Lyon wrote: > Hi, > > This is v2 of the patch series I sent in > https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657065.html. > > I have taken into account the feedback I received, and added more > patches to the series, converting more MVE intrinsics to the ne

Re: [PATCH 2/3]AArch64: support encoding integer immediates using floating point moves

Tamar Christina writes: > Hi All, > > This patch extends our immediate SIMD generation cases to support generating > integer immediates using floating point operation if the integer immediate > maps > to an exact FP value. > > As an example: > > uint32x4_t f1() { > return vdupq_n_u32(0x3f8000

Re: [PATCH v2 36/36] arm: [MVE intrinsics] use long_type_suffix / half_type_suffix helpers

On 04/09/2024 14:26, Christophe Lyon wrote: > In several places we are looking for a type twice or half as large as > the type suffix: this patch introduces helper functions to avoid code > duplication. long_type_suffix is similar to the SVE counterpart, but > adds an 'expected_tclass' parameter.

Re: [PATCH v2 35/36] arm: [MVE intrinsics] rework vsbcq vsbciq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vsbcq vsbciq using the new MVE builtins framework. > > We re-use most of the code introduced by the previous patches. > > 2024-08-28 Christophe Lyon > > gcc/ > > * config/arm/arm-mve-builtins-base.cc (class vadc_vsbc_impl):

Re: [PATCH v2 34/36] arm: [MVE intrinsics] rework vadcq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vadcq using the new MVE builtins framework. > > We re-use most of the code introduced by the previous patch to support > vadciq: we just need to initialize carry from the input parameter. > > 2024-08-28 Christophe Lyon > > gcc/ >

Re: [PATCH v2 32/36] arm: [MVE intrinsics] factorize vadc vadci vsbc vsbci

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vadc/vsbc and vadci/vsbci so that they use the same > parameterized names. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/iterators.md (mve_insn): Add VADCIQ_M_S, VADCIQ_M_U, > VADCIQ_U, VADCIQ_S, VADCQ_M_S, VADC

Re: [PATCH 3/3] bpf: set index entry for a VAR_DECL in CO-RE relocs

On 30-09-2024 18:47, David Faust wrote: On 9/27/24 09:49, Cupertino Miranda wrote: CO-RE accesses with non pointer struct variables will also generate a "0" string access within the CO-RE relocation. The first index within the access string, has sort of a different meaning then the remainin

RE: [PATCH 3/4]AArch64: enable zero-extends using TBLs for Adv. SIMD

Hi Kyrill, > -Original Message- > From: Kyrylo Tkachov > Sent: Monday, October 14, 2024 12:15 PM > To: Tamar Christina > Cc: GCC Patches ; nd ; Richard > Earnshaw ; ktkac...@gcc.gnu.org; Richard > Sandiford > Subject: Re: [PATCH 3/4]AArch64: enable zero-extends using TBLs for Adv. SIMD

[PATCH v2] bpf: make sure CO-RE relocs are typed with struct BTF_KIND_STRUCT

Hi everyone, Here is the v2 for the patch in this thread: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665378.html Please noticed that commit message was adapted to new content. Regards, Cupertino Based on observation within bpf-next selftests and comparisson of GCC and clang compile

Re: [PATCH v2 33/36] arm: [MVE intrinsics] rework vadciq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vadciq using the new MVE builtins framework. > > 2024-08-28 Christophe Lyon > gcc/ > > * config/arm/arm-mve-builtins-base.cc (class vadc_vsbc_impl): New. > (vadciq): New. > * config/arm/arm-mve-builtins-base.def (v

[PATCH v2] passes: Remove limit on the number of params

Having a limit of 2 params for NEXT_PASS was just done because I didn't think there was a way to handle arbitrary number of params. But I found that we can handle this via a static const variable array (constexpr so we know it is true or false at compile time) and just loop over the array. Note

Re: [PATCH v2 31/36] arm: [MVE intrinsics] add vadc_vsbc shape

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vadc_vsbc shape description. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (vadc_vsbc): New. > * config/arm/arm-mve-builtins-shapes.h (vadc_vsbc): New. OK. R. > --- > gcc

Re: [PATCH v2 30/36] arm: [MVE intrinsics] remove vshlcq useless expanders

On 04/09/2024 14:26, Christophe Lyon wrote: > Since we rewrote the implementation of vshlcq intrinsics, we no longer > need these expanders. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-builtins.cc > (arm_ternop_unone_none_unone_imm_qualifiers) > (-arm_ter

Re: [PATCH v2 29/36] arm: [MVE intrinsics] rework vshlcq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vshlc using the new MVE builtins framework. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (class vshlc_impl): New. > (vshlc): New. > * config/arm/arm-mve-builtins-base.def (vshlcq)

Re: [PATCH v2 28/36] arm: [MVE intrinsics] add vshlc shape

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vshlc shape description. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (vshlc): New. > * config/arm/arm-mve-builtins-shapes.h (vshlc): New. OK. R. > --- > gcc/config/arm/

Re: [PATCH v2 23/36] arm: [MVE intrinsics] factorize vdwdup viwdup

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vdwdup and viwdup so that they use the same parameterized > names. > > Like with vddup and vidup, we do not bother with the corresponding > expanders, as we stop using them in a subsequent patch. > > The patch also adds the missing attribute

Re: [PATCH v2 27/36] arm: [MVE intrinsics] remove useless v[id]wdup expanders

On 04/09/2024 14:26, Christophe Lyon wrote: > Like with vddup/vidup, we use code_for_mve_q_wb_u_insn, so we can drop > the expanders and their declarations as builtins, now useless. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-builtins.cc > (arm_quinop_unone_uno

Re: [releases/gcc-13 PATCH 0/2] Two backports (Valgrind noise, wrong-code)

Sam James writes: > Two backports for Valgrind noise (PR109920, PR116808) and wrong-code > (PR109934, PR117100). > > OK? Bootstrapped and regtested with no regressions. > > Aldy Hernandez (2): > Use delete[] in int_range destructor [PR109920] > Remove buggy special case in irange::invert [PR1

Re: [PATCH v2 26/36] arm: [MVE intrinsics] update v[id]wdup tests

On 04/09/2024 14:26, Christophe Lyon wrote: > Testing v[id]wdup overloads with '1' as argument for uint32_t* does > not make sense: this patch adds a new 'unit32_t *a' parameter to foo2 > in such tests. > > The difference with v[id]dup tests (where we removed 'foo2') is that > in 'foo1' we test th

Re: [PATCH v2 25/36] arm: [MVE intrinsics] rework vdwdup viwdup

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vdwdup and viwdup using the new MVE builtins framework. > > In order to share more code with viddup_impl, the patch swaps operands > 1 and 2 in @mve_v[id]wdupq_m_wb_u_insn, so that the parameter > order is similar to what @mve_v[id]dupq_m_wb_

Re: libstdc++ fetch_add & fenv -- ecosystem questions

On Mon, 14 Oct 2024, Matthew Malcomson wrote: > 4. __atomic_feraiseexcept should be a builtin to avoid previously > unnecessary requirement to link libatomic. libatomic should be linked by default (with --as-needed); see bug 81358. But if your concern is e.g. libstdc++.so having DT_NEEDED fo

Re: [PATCH v2 24/36] arm: [MVE intrinsics] add vidwdup shape

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vidwdup shape description for vdwdup and viwdup. > > It is very similar to viddup, but accounts for the additional 'wrap' > scalar parameter. > > 2024-08-21 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-s

Re: [PATCH v2 22/36] arm: [MVE intrinsics] fix checks of immediate arguments

On 04/09/2024 14:26, Christophe Lyon wrote: > As discussed in [1], it is better to use "su64" for immediates in > intrinsics signatures in order to provide better diagnostics > (erroneous constants are not truncated for instance). This patch thus > uses su64 instead of ss32 in binary_lshift_unsign

Re: [PATCH v2 21/36] arm: [MVE intrinsics] remove v[id]dup expanders

On 04/09/2024 14:26, Christophe Lyon wrote: > We use code_for_mve_q_u_insn, rather than the expanders used by the > previous implementation, so we can remove the expanders and their > declaration as builtins. > > 2024-08-21 Christophe Lyon > > gcc/ > * config/arm/arm_mve_builtins.d

Re: [PATCH v2 20/36] arm: [MVE intrinsics] update v[id]dup tests

On 04/09/2024 14:26, Christophe Lyon wrote: > Testing v[id]dup overloads with '1' as argument for uint32_t* does not > make sense: instead of choosing the '_wb' overload, we choose the > '_n', but we already do that in the '_n' tests. > > This patch removes all such bogus foo2 functions. > > 2024

Re: [PATCH] libquadmath: Typo in powq summary

On Mon, 14 Oct 2024, Ivan Agarsky wrote: > Hello, > > since step 9 in "Basics: Contributing to GCC in 10 easy steps" says I > should not commit the first few patches, I kindly ask someone to commit > the following for me: > > libquadmath\ChangeLog: > > * math/powq.c: This file comes fr

Re: [PATCH v2 19/36] arm: [MVE intrinsics] rework vddup vidup

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vddup and vidup using the new MVE builtins framework. > > We generate better code because we take advantage of the two outputs > produced by the v[id]dup instructions. > > For instance, before: > ldr r3, [r0] > sub r2, r3

Re: [PATCH 0/5] Provide better definitions of NULL

On Sun, 13 Oct 2024, Alejandro Colomar wrote: > There are some regressions. Below is the diff of .sum files. In the > .log files, I see some errors saying `CRC mismatch`. Did I do anything > wrong? I am not familiar with the C++ modules implementation and do not have any suggestions for why c

Re: [PATCH v2 18/36] arm: [MVE intrinsics] add viddup shape

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the viddup shape description for vidup and vddup. > > This requires the addition of report_not_one_of and > function_checker::require_immediate_one_of to > gcc/config/arm/arm-mve-builtins.cc (they are copies of the aarch64 SVE > counter

Re: [PATCH v2 17/36] arm: [MVE intrinsics] factorize vddup vidup

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vddup and vidup so that they use the same parameterized > names. > > This patch updates only the (define_insn > "@mve_q_u_insn") patterns and does not bother with the > (define_expand "mve_vidupq_n_u") ones, because a subsequent > patch avoid

Re: [PATCH v2 16/36] arm: [MVE intrinsics] rework vctp

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vctp using the new MVE builtins framework. > > 2024-08-21 Christophe Lyon > > gcc/ChangeLog: > > * config/arm/arm-mve-builtins-base.cc (class vctpq_impl): New. > (vctp16q): New. > (vctp32q): New. > (vctp64q): New.

Re: [PATCH v2 15/36] arm: [MVE intrinsics] rework vorn

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vorn using the new MVE builtins framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (vornq): New. > * config/arm/arm-mve-builtins-base.def (vornq): New. > * config/arm/arm-mve

Re: [PATCH v2 14/36] arm: [MVE intrinsics] factorize vorn

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vorn so that they use parameterized names. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/iterators.md (MVE_INT_M_BINARY_LOGIC): Add VORNQ_M_S, > VORNQ_M_U. > (MVE_FP_M_BINARY_LOGIC): Add VORNQ_M_F. >

Re: [PATCH v2 13/36] arm: [MVE intrinsics] rework vbicq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vbicq using the new MVE builtins framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (vbicq): New. > * config/arm/arm-mve-builtins-base.def (vbicq): New. > * config/arm/arm-mv

Re: [PATCH v2 12/36] arm: [MVE intrinsics] rework vcvtaq vcvtmq vcvtnq vcvtpq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vcvtaq vcvtmq vcvtnq vcvtpq using the new MVE builtins > framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (vcvtaq): New. > (vcvtmq): New. > (vcvtnq): New. > (vcvtpq):

Re: [PATCH v2 11/36] arm: [MVE intrinsics] add vcvtx shape

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vcvtx shape description for vcvtaq, vcvtmq, > vcvtnq, vcvtpq. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (vcvtx): New. > * config/arm/arm-mve-builtins-shapes.h (vcvtx): Ne

Re: libstdc++ fetch_add & fenv -- ecosystem questions

Just to double-check: If C++ users don't really care about fenv, then: Would a feasible shortcut be to add a #pragma to avoid caring about about this for a given region (and use that pragma in libstdc++ in order to avoid the regression of needing to link against libatomic). The reason I'm looki

Re: [PATCH v2 10/36] arm: [MVE intrinsics] factorize vcvtaq vcvtmq vcvtnq vcvtpq

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vcvtaq vcvtmq vcvtnq vcvtpq builtins so that they use the > same parameterized names. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/iterators.md (mve_insn): Add VCVTAQ_M_S, VCVTAQ_M_U, > VCVTAQ_S, VCVTAQ_U, VCVT

Re: [PATCH v2 09/36] arm: [MVE intrinsics] rework vcvtbq_f16_f32 vcvttq_f16_f32 vcvtbq_f32_f16 vcvttq_f32_f16

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vcvtbq_f16_f32, vcvttq_f16_f32, vcvtbq_f32_f16 and > vcvttq_f32_f16 using the new MVE builtins framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (class vcvtxq_impl): New. > (vcvtbq

Re: [PATCH v2 08/36] arm: [MVE intrinsics] add vcvt_f16_f32 and vcvt_f32_f16 shapes

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vcvt_f16_f32 and vcvt_f32_f16 shapes descriptions. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (vcvt_f16_f32) > (vcvt_f32_f16): New. > * config/arm/arm-mve-builtins-s

Re: [PATCH v2 07/36] arm: [MVE intrinsics] factorize vcvtbq vcvttq

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vcvtbq, vcvttq so that they use the same parameterized > names. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/iterators.md (mve_insn): Add VCVTBQ_F16_F32, > VCVTTQ_F16_F32, VCVTBQ_F32_F16, VCVTTQ_F32_F16, VCVTBQ

Re: [PATCH v2 06/36] arm: [MVE intrinsics] rework vcvtq

On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vcvtq using the new MVE builtins framework. > > In config/arm/arm-mve-builtins-base.def, the patch also restores the > alphabetical order. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (class

Re: [PATCH v2 05/36] arm: [MVE intrinsics] add vcvt shape

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vcvt shape description. > > It needs to add a new type_suffix_info parameter to > explicit_type_suffix_p (), because vcvt uses overloads for type > suffixes for integer to floating-point conversions, but not for > floating-point to

Re: [PATCH v2 04/36] arm: [MVE intrinsics] factorize vcvtq

On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vcvtq so that they use parameterized names. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/iterators.md (mve_insn): Add VCVTQ_FROM_F_S, > VCVTQ_FROM_F_U, VCVTQ_M_FROM_F_S, VCVTQ_M_FROM_F_U, > VCVTQ_M_N_FROM

Re: [PATCH v2 03/36] arm: [MVE intrinsics] Cleanup arm-mve-builtins-functions.h

On 04/09/2024 14:26, Christophe Lyon wrote: > This patch brings no functional change but removes some code > duplication in arm-mve-builtins-functions.h and makes it easier to > read and maintain. > > It introduces a new expand_unspec () member of > unspec_based_mve_function_base and makes a few c

OpenACC 'nohost' clause: harmonize 'libgomp.oacc-{c-c++-common,fortran}/routine-nohost-1.*'

Hi! On 2021-07-22T00:20:13+0200, I wrote: > [...], I've now pushed "OpenACC 'nohost' clause" to > master branch in commit a61f6afbee370785cf091fe46e2e022748528307, [...] Via Tobias' recent commit 3269a722b7a03613e9c4e2862bc5088c4a17cc11 "Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP'

Re: [PATCH v2 02/36] arm: [MVE intrinsics] remove useless resolve from create shape

On 04/09/2024 14:26, Christophe Lyon wrote: > vcreateq have no overloaded forms, so there's no need for resolve (). > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (create_def): Remove > resolve. Wouldn't it be more usual to write (create_de

Re: [PATCH v2 01/36] arm: [MVE intrinsics] improve comment for orrq shape

On 04/09/2024 14:26, Christophe Lyon wrote: > Add a comment about the lack of "n" forms for floating-point nor 8-bit > integers, to make it clearer why we use build_16_32 for MODE_n. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (binary_orrq_def)

[PATCH v2 6/9] aarch64: Use symbols without offset to prevent relocation issues

Friday, September 13, 2024 Martin Storsjö wrote: >> When the offset is >= 1MB: >> >> adrp x0, symbol + offset % (1 << 20) // it prevents relocation overflow in >> IMAGE_REL_ARM64_PAGEBASE_REL21 >> add x0, x0, (offset & ~0xf) >> 12, lsl #12 // a workaround to support >> 4GB offset >> add x0,

Re: [PATCH 1/3] bpf: make sure CO-RE relocs are never typed with a BTF_KIND_CONST

Hi David, On 30-09-2024 18:24, David Faust wrote: On 9/27/24 09:49, Cupertino Miranda wrote: Based on observation within bpf-next selftests and comparisson of GCC and clang compiled code, the BPF loader expects all CO-RE relocations to point to BTF non const type nodes. --- gcc/btfout.cc

Re: [PATCH v4 2/2] arm: [MVE intrinsics] Improve vdupq_n implementation

On 30/07/2024 22:39, Christophe Lyon wrote: > Hi, > > v4 of patch 2/2 fixes a small mistake in 3 testcases, by relaxing the > expected q0 as result register into q[0-9]+ to account for codegen > differences depending on if the test is compiled with > -mfloat-abi=softfp or -mfloat-abi=hard. > > I

Re: [PATCH] SVE intrinsics: Fold svmul with constant power-of-2 operand to svlsl

Jennifer Schmitz writes: > [...] > @@ -54,25 +56,121 @@ TEST_UNIFORM_ZX (mul_w0_s16_m_untied, svint16_t, int16_t, >z0 = svmul_m (p0, z1, x0)) > > /* > -** mul_2_s16_m_tied1: > -** mov (z[0-9]+\.h), #2 > +** mul_4dupop1_s16_m_tied1: > +** mov (z[0-9]+)\.h, #4 > +**

[committed] libstdc++: Populate generic std::time_get's wide %c format [PR117135]

Tested x86_64-linux. Pushed to trunk. -- >8 -- I missed out the __timepunct specialization for the "generic" implementation when defining the %c format in r15-4016-gc534e37faccf48. libstdc++-v3/ChangeLog: PR libstdc++/117135 * config/locale/generic/time_members.cc (__tim

[committed] libstdc++: Constrain std::expected comparisons (P3379R0)

Tested x86_64-linux. Pushed to trunk. -- >8 -- This proposal of mine has been approved by LEWG and forwarded to LWG. I expect it to be voted into the draft without significant changes. libstdc++-v3/ChangeLog: * include/bits/version.def (constrained_equality): Bump value. * inclu

Re: [PATCH] genmatch: Revert recent genmatch changes, instead add custom diag_vfprintf routine [PR117110]

> Am 14.10.2024 um 15:27 schrieb Jakub Jelinek : > > On Mon, Oct 14, 2024 at 03:16:44PM +0200, Richard Biener wrote: >> Can you do a clean revert and separately instantiate the new feature? > > I'd need to revert the libcpp changes too and wanted to avoid that. > Even in genmatch.cc itself th

Re: [PATCH] libstdc++: Use std::move for iterator in ranges::fill [PR117094]

LGTM On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > Input iterators aren't required to be copyable. > > libstdc++-v3/ChangeLog: > > PR libstdc++/117094 > * include/bits/ranges_algobase.h (__fill_fn): Use std::move for > iterator that migh

Re: [PATCH] testsuite: arm: Update expected asm in no-literal-pool-m0.c

On 10/14/24 16:40, Torbjorn SVENSSON wrote: Hi Christophe, On 2024-10-14 14:16, Christophe Lyon wrote: Hi Torbjörn, On 10/13/24 19:37, Torbjörn SVENSSON wrote: Ok for trunk? -- With the changes in r15-1579-g792f97b44ff, the constants have been updated. This patch aligns the constants in

[PATCH] testsuite: Add necessary dejagnu directives to pr115815_0.c

Hi, I have received an email from the Linaro infrastructure that the test gcc.dg/lto/pr115815_0.c which I added is failing on arm-eabi and I realized that not only it is missing dg-require-effective-target global_constructor but actually any dejagnu directives at all, which means it is unnecessari

[PATCH 7/7] fortran: Evaluate once BACK argument of MINLOC/MAXLOC with DIM [PR90608]

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Evaluate the BACK argument of MINLOC/MAXLOC once before the scalarization loops in the case where the DIM argument is present. This is a follow-up to r15-1994-ga55d24b3cf7f4d07492bb8e6fcee5571

RE: [PATCH 2/2]middle-end: use two's complement equality when comparing IVs during candidate selection [PR114932]

ping > -Original Message- > From: Tamar Christina > Sent: Monday, September 23, 2024 8:41 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: RE: [PATCH 2/2]middle-end: use two's complement equality when > comparing IVs during candidate selectio

[PATCH 6/7] fortran: Check for empty MINLOC/MAXLOC ARRAY along DIM only

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- In the function generating inline code to implement MINLOC and MAXLOC, only check for ARRAY size along DIM if DIM is present. The check for ARRAY emptyness had been checking the size of the fu

RE: [PATCH 1/2]middle-end: refactor type to be explicit in operand_equal_p [PR114932]

ping > -Original Message- > From: Tamar Christina > Sent: Monday, September 23, 2024 8:41 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: RE: [PATCH 1/2]middle-end: refactor type to be explicit in > operand_equal_p [PR114932] > > ping > >

  1   2   >