Re: [PATCH] i386: Modify testcases failed under -DDEBUG

On Mon, Jan 22, 2024 at 10:31 AM Haochen Jiang wrote: > > Hi all, > > Recently, I happened to run i386.exp under -DDEBUG and found some fail. > > This patch aims to fix that. Ok for trunk? OK. > > Thx, > Haochen > > gcc/testsuite/ChangeLog: > > * gcc.target/i386/adx-check.h: Include stdio.

Re: [Fortran] half-cycle trig functions and atan[d] fixes

Hi, > Hopefully, FX sees this as my emails to gmail bounce. I am seeing this email. > Now, if > the OS adds cospi() to libm and it's in libm's symbol map, then the > cospi() used by gfortran depends on the search order of the loaded > libraries. We only include the fallback math functions in l

[PATCH] aarch64: Re-enable ldp/stp fusion pass

Hi, Since, to the best of my knowledge, all reported regressions related to the ldp/stp fusion pass have now been fixed, and PGO+LTO bootstrap with --enable-languages=all is working again with the passes enabled, this patch turns the passes back on by default, as agreed with Jakub here: https://g

[PATCH] testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-bit Solaris/x86

gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its introduction in commit 43201f2c2173894bf7c423cad6da1c21567e06c0 Author: Roger Sayle Date: Mon May 30 21:20:09 2022 +0100 PR target/70321: Split double word equality/inequality after STV on x86. FAIL: gcc.target/i386/pr70321.c

[PATCH] testsuite: i386: Fix gcc.target/i386/pr80833-1.c on 32-bit Solaris/x86

gcc.target/i386/pr80833-1.c FAILs on 32-bit Solaris/x86 since 20220609: FAIL: gcc.target/i386/pr80833-1.c scan-assembler pextrd Unlike e.g. Linux/i686, 32-bit Solaris/x86 defaults to -mstackrealign, so this patch overrides that to match. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. Ok f

Re: [PATCH] testsuite: i386: Fix gcc.target/i386/pr80833-1.c on 32-bit Solaris/x86

On Wed, Jan 24, 2024 at 10:07 AM Rainer Orth wrote: > > gcc.target/i386/pr80833-1.c FAILs on 32-bit Solaris/x86 since 20220609: > > FAIL: gcc.target/i386/pr80833-1.c scan-assembler pextrd > > Unlike e.g. Linux/i686, 32-bit Solaris/x86 defaults to -mstackrealign, > so this patch overrides that to m

Re: [Fortran] half-cycle trig functions and atan[d] fixes

On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: > > Now, if > > the OS adds cospi() to libm and it's in libm's symbol map, then the > > cospi() used by gfortran depends on the search order of the loaded > > libraries. > > We only include the fallback math functions in libgfortran when they are

[PATCH] testsuite: i386: Fix gcc.target/i386/avx512vl-stv-rotatedi-1.c on 32-bit Solaris/x86

gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86 since its introduction in commit 4814b63c3c2326cb5d7baa63882da60ac011bd97 Author: Roger Sayle Date: Mon Jul 10 09:04:29 2023 +0100 i386: Add AVX512 support for STV of SI/DImode rotation by constant. FAIL: gcc.target/i38

RE: [PATCH] aarch64: Re-enable ldp/stp fusion pass

Hi Alex, > -Original Message- > From: Alex Coplan > Sent: Wednesday, January 24, 2024 8:34 AM > To: gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw ; Richard Sandiford > ; Kyrylo Tkachov ; > Jakub Jelinek > Subject: [PATCH] aarch64: Re-enable ldp/stp fusion pass > > Hi, > > Since, to th

[PATCH] LoongArch: Fix incorrect return type for frecipe/frsqrte intrinsic functions

gcc/ChangeLog: * config/loongarch/larchintrin.h (__frecipe_s): Update function return type. (__frecipe_d): Ditto. (__frsqrte_s): Ditto. (__frsqrte_d): Ditto. gcc/testsuite/ChangeLog: * gcc.target/loongarch/larch-frecipe-intrinsic.c: New test. diff

[PATCH] Loongarch: Remove vec_concatz pattern

It is incorrect to use vld/vori to implement the vec_concatz because when the LSX instruction is used to update the value of the vector register, the upper 128 bits of the vector register will not be zeroed. gcc/ChangeLog: * config/loongarch/lasx.md (@vec_concatz): Remove this define_i

[PATCH]AArch64: Fix expansion of Advanced SIMD div and mul using SVE [PR109636]

Hi All, As suggested in the ticket this replaces the expansion by converting the Advanced SIMD types to SVE types by simply printing out an SVE register for these instructions. This fixes the subreg issues since there are no subregs involved anymore. Bootstrapped Regtested on aarch64-none-linux-

[PATCH]AArch64: Do not allow SIMD clones with simdlen 1 [PR113552]

Hi All, The AArch64 vector PCS does not allow simd calls with simdlen 1, however due to a bug we currently do allow it for num == 0. This causes us to emit a symbol that doesn't exist and we fail to link. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? and for bac

Re: [PATCH]AArch64: Do not allow SIMD clones with simdlen 1 [PR113552]

Tamar Christina writes: > Hi All, > > The AArch64 vector PCS does not allow simd calls with simdlen 1, > however due to a bug we currently do allow it for num == 0. > > This causes us to emit a symbol that doesn't exist and we fail to link. > > Bootstrapped Regtested on aarch64-none-linux-gnu and

Re: [PATCH] aarch64: Re-enable ldp/stp fusion pass

On 24/01/2024 09:15, Kyrylo Tkachov wrote: > Hi Alex, > > > -Original Message- > > From: Alex Coplan > > Sent: Wednesday, January 24, 2024 8:34 AM > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Earnshaw ; Richard Sandiford > > ; Kyrylo Tkachov ; > > Jakub Jelinek > > Subject: [PATCH] aa

[PATCH v1] LoongArch: Adjust cost of vector_stmt that match multiply-add pattern.

We found that when only 128-bit vectorization was enabled, 549.fotonik3d_r failed to vectorize effectively. For this reason, we adjust the cost of 128-bit vector_stmt that match the multiply-add pattern to facilitate 128-bit vectorization. The experimental results show that after the modification,

[PATCH] testsuite: i386: Don't restrict gcc.dg/vect/vect-simd-clone-16c.c etc. to it686 [PR113556]

A couple of gcc.dg/vect/vect-simd-clone-1*.c tests FAIL on 32-bit Solaris/x86 since 20230222: FAIL: gcc.dg/vect/vect-simd-clone-16c.c scan-tree-dump-times vect "[nr] [^n]* = foo.simdclone" 2 FAIL: gcc.dg/vect/vect-simd-clone-16d.c scan-tree-dump-times vect "[nr] [^n]*

Re: [PATCH]AArch64: Fix expansion of Advanced SIMD div and mul using SVE [PR109636]

Tamar Christina writes: > Hi All, > > As suggested in the ticket this replaces the expansion by converting the > Advanced SIMD types to SVE types by simply printing out an SVE register for > these instructions. > > This fixes the subreg issues since there are no subregs involved anymore. > > Boots

[PATCH v1] LoongArch: Optimize implementation of single-precision floating-point approximate division.

We found that in the spec17 521.wrf program, some loop invariant code generated from single-precision floating-point approximate division calculation failed to propose a loop. This is because the pseudo-register that stores the intermediate temporary calculation results is rewritten in the implemen

Re: [PATCH] LoongArch: Fix incorrect return type for frecipe/frsqrte intrinsic functions

On Wed, 2024-01-24 at 17:19 +0800, Jiahao Xu wrote: > gcc/ChangeLog: > > * config/loongarch/larchintrin.h > (__frecipe_s): Update function return type. > (__frecipe_d): Ditto. > (__frsqrte_s): Ditto. > (__frsqrte_d): Ditto. > > gcc/testsuite/ChangeLog: > > * g

Re: [PATCH] LoongArch: Fix incorrect return type for frecipe/frsqrte intrinsic functions

在 2024/1/24 下午5:48, Xi Ruoyao 写道: On Wed, 2024-01-24 at 17:19 +0800, Jiahao Xu wrote: gcc/ChangeLog: * config/loongarch/larchintrin.h (__frecipe_s): Update function return type. (__frecipe_d): Ditto. (__frsqrte_s): Ditto. (__frsqrte_d): Ditto. gcc/test

Re: [PATCH] testsuite: i386: Don't restrict gcc.dg/vect/vect-simd-clone-16c.c etc. to it686 [PR113556]

On Wed, Jan 24, 2024 at 10:37:47AM +0100, Rainer Orth wrote: > A couple of gcc.dg/vect/vect-simd-clone-1*.c tests FAIL on 32-bit > Solaris/x86 since 20230222: > > FAIL: gcc.dg/vect/vect-simd-clone-16c.c scan-tree-dump-times vect > "[nr] [^n]* = foo.simdclone" 2 > FAIL: gcc.dg/vect

Re: [PATCH] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]

On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote： > The vect_int_mod target selector is evaluated with the options in > DEFAULT_VECTCFLAGS in effect, but these options are not automatically > passed to tests out of the vect directories. So this test fails on > targets where integer vector mo

[PATCH] [testsuite] Fix pretty printers regexps for GDB output

GDB emits end of lines as \r\n, we currently match the reverse \n\r, possibly leading to mismatches under racy conditions. I noticed this while running the GCC testsuite using the equivalent of GDB's READ1 feature [1] which helps detecting bufferization issues. Adjusting the first regexp to match

Re: [PATCH] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]

On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote: > On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote： > > The vect_int_mod target selector is evaluated with the options in > > DEFAULT_VECTCFLAGS in effect, but these options are not automatically > > passed to tests out of the vect direct

Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output

On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote: > > GDB emits end of lines as \r\n, we currently match the reverse \n\r, We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n > possibly leading to mismatches under racy conditions. What do we incorrectly match? Is the pr

[PATCH v1 1/4] Improve must tail in RTL backend

- Give error messages for all causes of non sibling call generation - Don't override choices of other non sibling call checks with must tail. This causes ICEs. The must tail attribute now only overrides flag_optimize_sibling_calls locally. - Error out when tree-tailcall failed to mark a must-tail c

[PATCH v1 3/4] Add tests for C++ musttail attribute

Mostly adopted from the existing C musttail plugin tests. --- gcc/testsuite/g++.dg/musttail1.C | 15 gcc/testsuite/g++.dg/musttail2.C | 35 ++ gcc/testsuite/g++.dg/musttail3.C | 42 gcc/testsuite/g++.dg/musttail4.C | 19

Re: [PATCH] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]

At 19:00 +0800 on Wednesday, 2024-01-24, Xi Ruoyao wrote： > On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote: > > On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote： > > > The vect_int_mod target selector is evaluated with the options in > > > DEFAULT_VECTCFLAGS in effect, but these option

[PATCH v1 4/4] Add documentation for musttail attribute

--- gcc/doc/extend.texi | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 0bc586d120e7..444b68f5d071 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -27890,7 +27890,8 @@ Predefined Macros,cpp,The GN

[PATCH v1 2/4] C++: Support clang compatible [[musttail]]

This patch implements a clang compatible [[musttail]] attribute for returns. musttail is useful as an alternative to computed goto for interpreters. With computed goto the interpreter function usually ends up very big which causes problems with register allocation and other per function optimizati

MAINTAINERS: Update my work email address

Hi! Pushed to master branch commit 7fcdb501366632fbf98a1eff275d76b9eea91aa1 "MAINTAINERS: Update my work email address", see attached. (Happy to talk, of course!) | Excited to announce that Sourcery Services are now available via BayLibre, ! 🧙‍♂️ | | GCC, GNU Toolchain

Re: [PATCH v1 2/4] C++: Support clang compatible [[musttail]]

Andi Kleen writes: > This patch implements a clang compatible [[musttail]] attribute for > returns. This is PR83324. See also PR52067 and PR110899. > > musttail is useful as an alternative to computed goto for interpreters. > With computed goto the interpreter function usually ends up very bi

[PATCH 0/2] RISC-V/testsuite: Add RTL if-conversion testcases

Hi, As discussed previously here are a bunch of RTL if-conversion testcases corresponding to and produced from existing pr105314.c and cset-sext.c C testcases. Verified with RV64 and RV32. OK to apply? Maciej

[PATCH 1/2] RISC-V/testsuite: Add RTL pr105314.c testcase variants

Add a pair of RTL tests, for RV64 and RV32 respectively, corresponding to the existing pr105314.c test. They have been produced from RTL code as at the entry of the "ce1" pass for pr105314.c compiled at -O3. gcc/testsuite/ * gcc.target/riscv/pr105314-rtl.c: New file. * g

[PATCH 2/2] RISC-V/testsuite: Add RTL cset-sext.c testcase variants

Add RTL tests, for RV64 and RV32 where appropriate, corresponding to the existing cset-sext.c tests. They have been produced from RTL code as at the entry of the "ce1" pass for the respective cset-sext.c tests built at -O3. gcc/testsuite/ * gcc.target/riscv/cset-sext-rtl.c: New

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

On Tue, 16 Jan 2024, Maciej W. Rozycki wrote: > > I don't have a strong opinion on this. I certainly see Andrew's point, but > > it's also the case that if some work earlier in the RTL or gimple pipeline > > comes along and compromises the test, then we'd see the failure and deal > > with > > it

Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971].

Richard Biener writes: > On Mon, 15 Jan 2024, Robin Dapp wrote: > >> I gave it another shot now by introducing a separate function as >> Richard suggested. It's probably not at the location he intended. >> >> The way I read the discussion there hasn't been any consensus >> on how (or rather wher

Re: [PATCH] AArch64: aarch64_class_max_nregs mishandles 64-bit structure modes [PR112577]

Tejas Belagod writes: > The target hook aarch64_class_max_nregs returns the incorrect result for > 64-bit > structure modes like V31DImode or V41DFmode etc. The calculation of the nregs > is based on the size of AdvSIMD vector register for 64-bit modes which ought > to > be UNITS_PER_VREG / 2.

Re: [PATCH] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]

On Wed, 2024-01-24 at 19:08 +0800, chenxiaolong wrote: > At 19:00 +0800 on Wednesday, 2024-01-24, Xi Ruoyao wrote： > > On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote: > > > On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote： > > > > The vect_int_mod target selector is evaluated with the

Re: [PATCH] aarch64: Check the ldp/stp policy model correctly when mem ops are reversed.

Manos Anagnostakis writes: > The current ldp/stp policy framework implementation was missing cases, where > the memory operands were reversed. Therefore the call to the framework > function > is moved after the lower mem check with the suitable parameters. Also removes > the mode of aarch64_opera

Re: [PATCH v1 2/4] C++: Support clang compatible [[musttail]]

Thanks for doing this. I'm not qualified to review the patch properly, but was just curious... Andi Kleen writes: > This patch implements a clang compatible [[musttail]] attribute for > returns. > > musttail is useful as an alternative to computed goto for interpreters. > With computed goto the

Re: [PATCH 2/2] libstdc++: Implement P2165R4 changes to std::pair/tuple/etc

On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote: > diff --git a/libstdc++-v3/include/bits/stl_pair.h > b/libstdc++-v3/include/bits/stl_pair.h > index b81b479ad43..a9b20fbe7ca 100644 > --- a/libstdc++-v3/include/bits/stl_pair.h > +++ b/libstdc++-v3/include/bits/stl_pair.h > @@ -85,12 +85,70 @@ _G

Re: [PATCH v2] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

Thank you for your help. I will update the test case. I test on the Coremark and have 5% improvement on the SiFive CPU. On Tue, Jan 23, 2024 at 12:24 PM Jeff Law wrote: > > > On 1/21/24 23:12, Monk Chiang wrote: > > Since the match.pd transforms (zero_one == 0) ? y : z y, > > into ((typeof(y))z

Re: [PATCH 2/2] libstdc++: Implement P2165R4 changes to std::pair/tuple/etc

On Wed, 24 Jan 2024 at 12:01, Jonathan Wakely wrote: > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote: > > diff --git a/libstdc++-v3/include/bits/stl_pair.h > > b/libstdc++-v3/include/bits/stl_pair.h > > index b81b479ad43..a9b20fbe7ca 100644 > > --- a/libstdc++-v3/include/bits/stl_pair.h > >

Re: [PATCH] x86: Update PR 35513 tests

Hi! On 2022-02-10T05:55:15-0800, "H.J. Lu via Gcc-patches" wrote: > 1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513 > run-time tests. Moving my x86_64-pc-linux-gnu testing from an old to a newish system (Ubuntu 20.04), I notice: [-PASS: g++.target/i386/pr35513-1.C -std=g

Re: [PATCH v1 2/4] C++: Support clang compatible [[musttail]]

> ...are the three hunks above needed? The reason for asking is that, > if they were needed, I'd have expected that we'd also need a table > entry for clang::musttail (which is possible to add). But trying it > locally, the patch seemed to work without this. Interesting thanks. I think I copied

Re: [PATCH v1 2/4] C++: Support clang compatible [[musttail]]

On Wed, Jan 24, 2024 at 11:13:44AM +, Sam James wrote: > > Andi Kleen writes: > > > This patch implements a clang compatible [[musttail]] attribute for > > returns. > > This is PR83324. See also PR52067 and PR110899. Thanks for the references. I'll add it there. > > > The attribute is onl

[PATCH] amdgcn: additional gfx1100 support

This 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 test failures to investigate, and probably some tuning to do. It might also get gfx1030 working too. @Richi, could you test it, please? I can't test the other

[PATCH v3] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

Since the match.pd transforms (zero_one == 0) ? y : z y, into ((typeof(y))zero_one * z) y. Add splitters to recongize this expression to generate SFB instructions. gcc/ChangeLog: PR target/113095 * config/riscv/sfb.md: New splitters to rewrite single bit sign extension as

Re: [PATCH] arm: Fix missing bti instruction for virtual thunks

On 23/01/2024 15:53, Richard Ball wrote: > Adds missing bti instruction at the beginning of a virtual > thunk, when bti is enabled. > > gcc/ChangeLog: > > * config/arm/arm.cc (arm_output_mi_thunk): Emit > insn for bti_c when bti is enabled. > > gcc/testsuite/ChangeLog: > > *

[PATCH] testsuite/vect: Add target checks to refined patterns [PR113558]

Hi, on Solaris/SPARC several vector tests appeared to be regressing. They were never vectorized but the checks before r14-3612-ge40edf64995769 would match regardless if a loop was actually vectorized or not. The refined checks only match a successful vectorization attempt but are run unconditiona

[PATCH] tree-optimization/113576 - non-empty latch and may_be_zero vectorization

We can't support niters with may_be_zero when we end up with a non-empty latch due to early exit peeling. At least not in the simplistic way the vectorizer handles this now. Disallow it again for exits that are not the last one. Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Re: [PATCH] libgccjit: Add support for creating temporary variables

On Fri, 2024-01-19 at 16:54 -0500, Antoni Boucher wrote: > Hi. > This patch adds a new way to create local variable that won't > generate > debug info: it is to be used for compiler-generated variables. > Thanks for the review. Thanks for the patch. > diff --git a/gcc/jit/docs/topics/compatibilit

Re: [PATCH] libgccjit: Add gcc_jit_global_set_readonly

On Fri, 2024-01-19 at 16:57 -0500, Antoni Boucher wrote: > Hi. > This patch adds a new API gcc_jit_global_set_readonly: it's > equivalent > to having a const global variable, but it is useful in the case of > complex compilers where it is not convenient to use const. > Thanks for the review. Hi An

[pushed] analyzer kernel plugin: implement __check_object_size [PR112927]

PR analyzer/112927 reports a false positive from -Wanalyzer-tainted-size seen on the Linux kernel's drivers/char/ipmi/ipmi_devintf.c with the analyzer kernel plugin. The issue is that in: (A): if (msg->data_len > 272) { return -90; } (B): n = msg->data_len; __check_object_size(to, n)

[pushed] analyzer: fix taint false +ve due to overzealous state purging [PR112977]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Successful run of analyzer integration tests on x86_64-pc-linux-gnu. Pushed to trunk as r14-8391-ge503f9aca91926. gcc/analyzer/ChangeLog: PR analyzer/112977 * engine.cc (impl_region_model_context::on_liveness_change): P

Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]

Ping! That's a one-line fix, and you can find all the details in the bugzilla entry. Also, I can provide executables built with the affected toolchains, demonstrating the problem and the fix. Thanks, Matteo Il 17/01/24 12:51, Matteo Italia ha scritto: SEH _Unwind_Resume_or_Rethrow invokes abo

Re: [PATCH] ipa-cp: Fix check for exceeding param_ipa_cp_value_list_size (PR 113490)

Hi, On Mon, Jan 22 2024, Jan Hubicka wrote: >> Hi, >> >> When the check for exceeding param_ipa_cp_value_list_size limit was >> modified to be ignored for generating values from self-recursive >> calls, it should have been changed from equal to, to equals toor is >> greater than. This omission m

Re: [PATCH 2/2] libstdc++: Implement P2165R4 changes to std::pair/tuple/etc

On Wed, 24 Jan 2024, Jonathan Wakely wrote: > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote: > > diff --git a/libstdc++-v3/include/bits/stl_pair.h > > b/libstdc++-v3/include/bits/stl_pair.h > > index b81b479ad43..a9b20fbe7ca 100644 > > --- a/libstdc++-v3/include/bits/stl_pair.h > > +++ b/libs

Re: [PATCH] libgccjit: Add gcc_jit_global_set_readonly

Yes, it is for a use case inside of rustc_codegen_gcc. The compiler is structured in a way where we don't know if a global variable might be constant when it is created. On Wed, 2024-01-24 at 10:09 -0500, David Malcolm wrote: > On Fri, 2024-01-19 at 16:57 -0500, Antoni Boucher wrote: > > Hi. > > T

Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

Am 22.01.24 um 08:45 schrieb Richard Biener: On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote: Am 18.01.24 um 20:54 schrieb Roger Sayle: This patch tweaks RTL expansion of multi-word shifts and rotates to use PLUS rather than IOR for disjunctive operations. During expansion of th

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

Hi, is it OK for trunk? I do not have access to the repo, can you please help me submit the patch? Thanks. xndcn 于2024年1月17日周三 00:16写道： > > Sorry about the mangled content... > So I add a new add-options for libatomic_16b: > > --- > libstdc++-v3/ChangeLog: > > * include/bits/atomic_base.h: add __

Re: [PATCH, V2] PR target/112886, Add %S to print_operand for vector pair support.

On 1/24/24 12:04 AM, Kewen.Lin wrote: > on 2024/1/24 11:11, Peter Bergner wrote: >> But not with this. The -mdejagnu-cpu=power10 option already enables -mvsx. >> If the user explcitly forces -mno-vsx via RUNTESTFLAGS, then let them. >> The options set in RUNTESTFLAGS come after the options in the

[patch] amdgcn: config.gcc - enable gfx1100 multilib; add gfx1100 to docs (was: [PATCH] amdgcn: additional gfx1100 support)

This patch obviously depends on Andrew's; he wrote in the previous email of this thread regarding his patch: Andrew Stubbs wrote: This 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 test failures to investigat

Re: [PATCH V2] rs6000: New pass for replacement of adjacent loads fusion (lxv).

Hi Ajit, On 21/01/2024 19:57, Ajit Agarwal wrote: > > Hello All: > > New pass to replace adjacent memory addresses lxv with lxvp. > Added common infrastructure for load store fusion for > different targets. Thanks for this, it would be nice to see the load/store pair pass generalized to multipl

Re: [PATCH 1/2] RISC-V/testsuite: Add RTL pr105314.c testcase variants

On 1/24/24 04:16, Maciej W. Rozycki wrote: Add a pair of RTL tests, for RV64 and RV32 respectively, corresponding to the existing pr105314.c test. They have been produced from RTL code as at the entry of the "ce1" pass for pr105314.c compiled at -O3. gcc/testsuite/ * gcc.targ

Re: [PATCH 2/2] RISC-V/testsuite: Add RTL cset-sext.c testcase variants

On 1/24/24 04:16, Maciej W. Rozycki wrote: Add RTL tests, for RV64 and RV32 where appropriate, corresponding to the existing cset-sext.c tests. They have been produced from RTL code as at the entry of the "ce1" pass for the respective cset-sext.c tests built at -O3. gcc/testsuite/

Re: [PATCH] libgccjit: Allow comparing array types

On Fri, 2024-01-19 at 16:55 -0500, Antoni Boucher wrote: > Hi. > This patch allows comparing different instances of array types as > equal. > Thanks for the review. Thanks; the patch looks good to me. Dave

Re: [PATCH] libgccjit: Allow comparing aligned int types

On Thu, 2023-12-21 at 08:33 -0500, Antoni Boucher wrote: > Hi. > This patch allows comparing aligned integer types as equal. > There's a TODO in the code about whether we should check that the > alignment is equal. > What are your thoughts on this? I think we should check for equal alignment. [..

[PATCH v4 0/4] Libatomic: Add LSE128 atomics support for AArch64

v4 updates 1. Make use of HWCAP2_LSE128, as defined in the Linux kernel v6.7 for feature check. This has required adding a new patch to the series, enabling ifunc resolvers to read a second arg of type `__ifunc_arg_t *', from which the `_hwcap2' member can be queried for LSE128 support

[PATCH v4 2/4] libatomic: Add support for __ifunc_arg_t arg in ifunc resolver

With support for new atomic features in Armv9.4-a being indicated by HWCAP2 bits, Libatomic's ifunc resolver must now query its second argument, of type __ifunc_arg_t*. We therefore make this argument known to libatomic, allowing us to query hwcap2 bits in the following manner: bool resolver

[PATCH v4 3/4] libatomic: Enable LSE128 128-bit atomics for armv9.4-a

The armv9.4-a architectural revision adds three new atomic operations associated with the LSE128 feature: * LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit value held in a pair of registers, with original data loaded into the same 2 registers. * LDSETP - Atomic OR (bitset) of

[PATCH v4 4/4] aarch64: Add explicit checks for implicit LSE/LSE2 requirements.

At present, Evaluation of both `has_lse2(hwcap)' and `has_lse128(hwcap)' may require issuing an `mrs' instruction to query a system register. This instruction, when issued from user-space results in a trap by the kernel which then returns the value read in by the system register. Given the undesi

[PATCH v4 1/4] libatomic: atomic_16.S: Improve ENTRY, END and ALIAS macro interface

The introduction of further architectural-feature dependent ifuncs for AArch64 makes hard-coding ifunc `_i' suffixes to functions cumbersome to work with. It is awkward to remember which ifunc maps onto which arch feature and makes the code harder to maintain when new ifuncs are added and their su

Re: [PATCH v3] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

On 1/24/24 05:54, Monk Chiang wrote: Since the match.pd transforms (zero_one == 0) ? y : z y, into ((typeof(y))zero_one * z) y. Add splitters to recongize this expression to generate SFB instructions. gcc/ChangeLog: PR target/113095 * config/riscv/sfb.md: New splitters to re

Re: [Fortran] half-cycle trig functions and atan[d] fixes

Am 24.01.24 um 10:13 schrieb Janne Blomqvist: On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: Now, if the OS adds cospi() to libm and it's in libm's symbol map, then the cospi() used by gfortran depends on the search order of the loaded libraries. We only include the fallback math function

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

On 1/24/24 04:26, Maciej W. Rozycki wrote: On Tue, 16 Jan 2024, Maciej W. Rozycki wrote: I don't have a strong opinion on this. I certainly see Andrew's point, but it's also the case that if some work earlier in the RTL or gimple pipeline comes along and compromises the test, then we'd see

Re: [PATCH 2/2] libstdc++: Implement P2165R4 changes to std::pair/tuple/etc

On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote: > > On Wed, 24 Jan 2024, Jonathan Wakely wrote: > > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote: > > > diff --git a/libstdc++-v3/include/bits/stl_pair.h > > > b/libstdc++-v3/include/bits/stl_pair.h > > > index b81b479ad43..a9b20fbe7ca 100

[PATCH v2 0/2] libatomic: AArch64 rcpc3 128-bit atomic operation enablement

The introduction of the optional RCPC3 architectural extension for Armv8.2-A upwards provides additional support for the release consistency model, introducing both the Load-Acquire RCpc Pair Ordered, and Store-Release Pair Ordered operations in the form of LDIAPP and STILP. In light of this, cont

[PATCH v2 1/2] libatomic: Increase max IFUNC_NCOND(N) from 3 to 4.

libatomic/ChangeLog: * libatomic_i.h: Add GEN_SELECTOR implementation for IFUNC_NCOND(N) == 4. --- libatomic/libatomic_i.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/libatomic/libatomic_i.h b/libatomic/libatomic_i.h index 861a22da152..0a854fd908c 100644

[PATCH v2 2/2] libatomic: Add rcpc3 128-bit atomic operations for AArch64

The introduction of the optional RCPC3 architectural extension for Armv8.2-A upwards provides additional support for the release consistency model, introducing the Load-Acquire RCpc Pair Ordered, and Store-Release Pair Ordered operations in the form of LDIAPP and STILP. These operations are single

Re: [PATCH] libgccjit: Add convert vector

On Thu, 2023-12-21 at 16:01 -0500, Antoni Boucher wrote: > Hi. > This patch adds the support for the convert vector internal function. Thanks for the patch. > I'll need to double-check that making the decl a register is > necessary. I confess I don't know anything about this aspect of the patch,

[PATCH] Fix vect_long_mult for aarch64 [PR109705]

On aarch64, vectorization of `long` multiply can be done if SVE is enabled or if long is 32bit (ILP32). It can also be done for constants too but there is no effective target test for that just yet. Build and tested on aarch64-linux-gnu with no regressions (also tested with SVE enabled). gcc/tes

Re: [PATCH] aarch64: Fix eh_return for -mtrack-speculation [PR112987]

Szabolcs Nagy writes: > Recent commit introduced a conditional branch in eh_return epilogues > that is not compatible with speculation tracking: > > commit 426fddcbdad6746fe70e031f707fb07f55dfb405 > Author: Szabolcs Nagy > CommitDate: 2023-11-27 15:52:48 + > > aarch64: Use br inst

Re: [PATCH] aarch64: Fix __builtin_apply with -mgeneral-regs-only [PR113486]

Andrew Pinski writes: > The problem here is the builtin apply mechanism thinks the FP registers > are to be used due to get_raw_arg_mode not returning VOIDmode. This > fixes that oversight and the backend now returns VOIDmode for non-general-regs > if TARGET_GENERAL_REGS_ONLY is true. > > Built an

Re: [PATCH] testsuite: require libc sym for -shared

On 1/23/24 00:15, Alexandre Oliva wrote: Targets whose binutils support -shared, but that don't have a shared libc, and that can't add PDC (non-PIC) to shared libraries, may succeed at the effective target test for -shared, because it brings nothing from libc, but tests that rely on -shared a

Re: [PATCH] testsuite: no dfp run without dfprt

On 1/23/24 00:13, Alexandre Oliva wrote: newlib-src/libc/include/sys/fenv.h doesn't define the FE_* macros that libgcc expects to enable decimal float support. Only after newlib is configured and built does an overriding header that defines those macros become available in objdir//newlib/tar

Re: [PATCH] libgccjit: Fix float playback for cross-compilation

On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote: > Hi. > This patch fixes the bug 113343. > I'm wondering if there's a better solution than using mpfr. > The only other solution I found is real_from_string, but that seems > overkill to convert the number to a string. > I could not find a be

Re: [PATCH] Fix vect_long_mult for aarch64 [PR109705]

Andrew Pinski writes: > On aarch64, vectorization of `long` multiply can be done if SVE is enabled > or if long is 32bit (ILP32). It can also be done for constants too but there > is no effective target test for that just yet. > > Build and tested on aarch64-linux-gnu with no regressions (also tes

Re: [PATCH] jit, Darwin: Implement library exports list.

On Tue, 2024-01-16 at 11:10 +, Iain Sandoe wrote: > Tested on x86_64, i686 Darwin and x86_64 Linux, > OK for trunk? when ? > thanks, > Iain Hi Iain, thanks for the patch. I'll have to defer to your Darwin expertise here; given that you've tested it on the above configurations I'll assume it's

Re: [PATCH] testsuite, jit: Stabilize error output.

On Tue, 2024-01-16 at 11:12 +, Iain Sandoe wrote: > Tested on x86_64, i686 Darwin, x86_64 Linux, > OK for trunk? When? > thanks > Iain Thanks; looks good to me for trunk. Given that the scope is just the jit testsuite and that you've tested it on 3 configurations (and presumably made use of t

Re: [PATCH] Fortran: passing of optional dummies to elemental procedures [PR113377]

Le 23/01/2024 à 21:36, Harald Anlauf a écrit : Dear all, here's the second part of a series for the treatment of missing optional arguments passed to optional dummies, now fixing the case that the latter procedures are elemental. Adjustments were necessary when the missing dummy has the VALUE a

Re: [PATCH 2/2] libstdc++: Implement P2165R4 changes to std::pair/tuple/etc

On Wed, 24 Jan 2024, Jonathan Wakely wrote: > On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote: > > > > On Wed, 24 Jan 2024, Jonathan Wakely wrote: > > > > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote: > > > > diff --git a/libstdc++-v3/include/bits/stl_pair.h > > > > b/libstdc++-v3/inclu

Re: [Fortran] half-cycle trig functions and atan[d] fixes

On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote: > On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: > > > Now, if > > > the OS adds cospi() to libm and it's in libm's symbol map, then the > > > cospi() used by gfortran depends on the search order of the loaded > > > libraries. >

[no subject]

This version addresses all the feedback so far (Thanks!). The largest change is support for using [[musttail]] in C23, not just C++. -Andi

[PATCH v2 1/5] Improve must tail in RTL backend

- Give error messages for all causes of non sibling call generation - Don't override choices of other non sibling call checks with must tail. This causes ICEs. The must tail attribute now only overrides flag_optimize_sibling_calls locally. - Error out when tree-tailcall failed to mark a must-tail c

[PATCH v2 3/5] C: Implement musttail attribute for returns

Implement a C23 clang compatible musttail attribute similar to the earlier C++ implementation in the C parser. --- gcc/c/c-parser.cc | 59 +-- gcc/c/c-tree.h| 2 +- gcc/c/c-typeck.cc | 15 ++-- 3 files changed, 61 insertions(+), 15 deletions

[PATCH v2 2/5] C++: Support clang compatible [[musttail]] (PR83324)

This patch implements a clang compatible [[musttail]] attribute for returns. musttail is useful as an alternative to computed goto for interpreters. With computed goto the interpreter function usually ends up very big which causes problems with register allocation and other per function optimizati

[PATCH v2 5/5] Add documentation for musttail attribute

--- gcc/doc/extend.texi | 16 1 file changed, 16 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 0bc586d120e7..c68d32bed8de 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -9867,6 +9867,22 @@ foo (int x, int y) @code{y} is not actually in

  1   2   >