Re: [PATCH] builtins: Force SAVE_EXPR for __builtin_{add, sub, mul}_overflow and __builtin{add,sub}c [PR108789]

On Tue, 4 Jun 2024, Jakub Jelinek wrote: > Hi! > > The following testcase is miscompiled, because we use save_expr > on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first > two operands are not INTEGER_CSTs (in that case we just fold it right away) > but are TREE_READONLY/!TREE_SI

Re: [PATCH 4/13 ver 3] rs6000, extend the current vec_{un,}signed{e,o} built-ins

Hi, on 2024/5/29 23:58, Carl Love wrote: > Updated the patch per the feedback comments from the previous version. > > Carl > --- > > rs6000, extend the current vec_{un,}signed{e,o} built-ins > > The built-ins

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

On Mon, Jun 3, 2024 at 4:48 PM David Malcolm wrote: > > On Mon, 2024-06-03 at 08:29 +0200, Richard Biener wrote: > > On Fri, May 31, 2024 at 11:23 PM Qing Zhao > > wrote: > > > > > > > > > > > > > On May 23, 2024, at 07:46, Richard Biener > > > > wrote: > > > > > > > > On Wed, May 22, 2024 at 8:

Re: [patch] libgomp: Enable USM for some nvptx devices

On 03/06/2024 21:40, Tobias Burnus wrote: Andrew Stubbs wrote: On 03/06/2024 17:46, Tobias Burnus wrote: Andrew Stubbs wrote: +    /* If USM has been requested and is supported by all devices +   of this type, set the capability accordingly. */ +    if (omp_requires_mask & GOMP

Re: [PATCH] Fix PR c++/111106: missing ; causes internal compiler error

Hi Jason, Thanks for the review. On 31 May 2024, at 22:45, Jason Merrill wrote: > On 5/30/24 07:31, Simon Martin wrote: >> We currently fail upon the following because an assert in >> dependent_type_p >> fails for f's parameter >> >> === cut here === >> consteval int id (int i) { return i; } >>

[Patch, PR Fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

Hi all, attached patch fixes a memory leak when a user-defined function returns a polymorphic type/class. The issue was, that the polymorphic type was not detected correctly and therefore the len-field was not transferred correctly. Regtests ok x86_64-linux/Fedora 39. Ok for master? Regards,

RFC: Support for pragma clang loop interleave_count(N)

Hi, We got a question as to whether GCC had something similar to llvm's pragma clang loop interleave_count(N), see https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations I did a quick hack, using 'GCC interleaves N', just as a proof of concept, to see wheth

Re: RFC: Support for pragma clang loop interleave_count(N)

On Tue, Jun 04, 2024 at 11:58:43AM +0100, Andre Vieira (lists) wrote: > case annot_expr_unroll_kind: > + case annot_expr_interleaves_kind: > { > - pp_string (pp, ", unroll "); > + pp_string (pp, > +annot_expr_unroll_kind I think annot_expr_unro

[COMMITTED] testsuite: i386: Require ifunc support in gcc.target/i386/avx10_1-25.c etc.

Two new AVX10.1 tests FAIL on Solaris/x86: FAIL: gcc.target/i386/avx10_1-25.c (test for excess errors) FAIL: gcc.target/i386/avx10_1-26.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/avx10_1-25.c:6:9: error: the call requires 'ifunc', which i

Re: [PATCH 02/52 v2] d: Replace use of LONG_DOUBLE_TYPE_SIZE

Excerpts from Kewen.Lin's message of Juni 4, 2024 5:17 am: > Hi Iain, > > on 2024/6/3 22:39, Iain Buclaw wrote: >> Excerpts from Kewen.Lin's message of Juni 3, 2024 10:57 am: >>> Hi Iain, >>> >>> on 2024/6/3 16:40, Iain Buclaw wrote: Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am:

Re: RFC: Support for pragma clang loop interleave_count(N)

On Tue, 4 Jun 2024, Andre Vieira (lists) wrote: > Hi, > > We got a question as to whether GCC had something similar to llvm's pragma > clang loop interleave_count(N), see > https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations > > I did a quick hack, using 'G

Re: [PATCH] Implement -fassume-sane-operator-new [PR110137]

On Wed, May 29, 2024 at 04:09:08AM +, user202...@protonmail.com wrote: > This patch implements the flag -fassume-sane-operator-new as suggested in > PR110137. When the flag is enabled, it is assumed that operator new does not > modify global memory. > > While this patch is not powerful enoug

Re: RFC: Support for pragma clang loop interleave_count(N)

On 04/06/2024 12:50, Richard Biener wrote: On Tue, 4 Jun 2024, Andre Vieira (lists) wrote: Hi, We got a question as to whether GCC had something similar to llvm's pragma clang loop interleave_count(N), see https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimiza

[PATCH] Record edge true/false value for gcov

Make gcov aware which edges are the true/false to more accurately reconstruct the CFG. There are plenty of bits left in arc_info and it opens up for richer reporting. gcc/ChangeLog: * gcov-io.h (GCOV_ARC_TRUE): New. (GCOV_ARC_FALSE): New. * gcov.cc (struct arc_info): Add

PATCH] AArch64: Fix cpu features initialization [PR115342]

Fix CPU features initialization. Use HWCAP rather than explicit accesses to CPUID registers. Perform the initialization atomically to avoid multi- threading issues. Passes regress, OK for commit and backport? libgcc: PR target/115342 * config/aarch64/cpuinfo.c (__init_cpu_featu

Re: [PATCH 5/6] vect: Support multiple lane-reducing operations for loop reduction [PR114440]

On Sun, Jun 2, 2024 at 4:13 PM Feng Xue OS wrote: > > Please see my comments below. > > Thanks, > Feng > > > On Thu, May 30, 2024 at 4:55 PM Feng Xue OS > > wrote: > >> > >> For lane-reducing operation(dot-prod/widen-sum/sad) in loop reduction, > >> current > >> vectorizer could only handle the

Re: [PATCH v1] Internal-fn: Add new IFN mask_len_strided_load/store

On Tue, May 28, 2024 at 5:15 AM wrote: > > From: Pan Li > > This patch would like to add new internal fun for the below 2 IFN. > * mask_len_strided_load > * mask_len_strided_store > > The GIMPLE v = MASK_LEN_STRIDED_LOAD (ptr, stride, mask, len, bias) will > be expanded into v = mask_len_strided_

Re: PATCH] AArch64: Fix cpu features initialization [PR115342]

Wilco Dijkstra writes: > Fix CPU features initialization. Use HWCAP rather than explicit accesses > to CPUID registers. Perform the initialization atomically to avoid multi- > threading issues. Please describe the problem that the patch is fixing. I think the PR description would make a better

[PATCH] fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]

Hi! The function currently incorrectly assumes all the __builtin_clz* and .CLZ calls have non-negative result. That is the case of the former which is UB on zero and has [0, prec-1] return value otherwise, and is the case of the single argument .CLZ as well (again, UB on zero), but for two argume

[PATCH] fold-const, gimple-fold: Some formatting cleanups

Hi! While looking into PR115337, I've spotted some badly formatted code, which the following patch fixes. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-06-04 Jakub Jelinek * fold-const.cc (tree_call_nonnegative_warnv_p): Formatting fixes. (tree_inv

Re: [RFC/RFA] [PATCH 08/12] Add a new pass for naive CRC loops detection

Sorry for the late response; somehow, I didn't receive the last few messages. >>* Am 30.05.2024 um 00:31 schrieb Jeff Law >>: *>> >>*  *>> >>>* On 5/28/24 1:01 AM, Richard Biener wrote: ** On Fri, May 24, 2024 at 10:46 AM Mariam Arutunian ** > wrote: * * This patch adds a new comp

[PATCH] ranger: Improve CLZ fold_range [PR115337]

Hi! cfn_ctz::fold_range includes special cases for the case where .CTZ has two arguments and so is well defined at zero, and the second argument is equal to prec or -1, but cfn_clz::fold_range does that only for the prec case. -1 is fairly common as well though, because the builtins do use it no

[PATCH] fold-const: Handle CTZ like CLZ in tree_call_nonnegative_warnv_p [PR115337]

Hi! I think we can handle CTZ exactly like CLZ in tree_call_nonnegative_warnv_p. Like CLZ, if it is UB at zero, the result range is [0, prec-1] and if it is well defined at zero, the second argument provides the value at zero. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Re: [PATCH] fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]

On Tue, 4 Jun 2024, Jakub Jelinek wrote: > Hi! > > The function currently incorrectly assumes all the __builtin_clz* and .CLZ > calls have non-negative result. That is the case of the former which is UB > on zero and has [0, prec-1] return value otherwise, and is the case of the > single argumen

Re: [PATCH] fold-const, gimple-fold: Some formatting cleanups

On Tue, 4 Jun 2024, Jakub Jelinek wrote: > Hi! > > While looking into PR115337, I've spotted some badly formatted code, > which the following patch fixes. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Looks obvious to me. Richard. > 2024-06-04 Jakub Jelinek > >

Re: [PATCH] fold-const: Handle CTZ like CLZ in tree_call_nonnegative_warnv_p [PR115337]

On Tue, 4 Jun 2024, Jakub Jelinek wrote: > Hi! > > I think we can handle CTZ exactly like CLZ in tree_call_nonnegative_warnv_p. > Like CLZ, if it is UB at zero, the result range is [0, prec-1] and if it is > well defined at zero, the second argument provides the value at zero. > > Bootstrapped/r

Re: [PATCH v6 1/8] Improve must tail in RTL backend

Hello, On Mon, 3 Jun 2024, Jakub Jelinek wrote: > > Hmm. I count six tests in about 25 lines of code in > > tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p. > > > > Are you perhaps worrying about the sibcall discovery itself (i.e. much of > > find_tail_calls)? Why w

Re: [PATCH 1/2] Simplify (AND (ASHIFTRT A imm) mask) to (LSHIFTRT A imm) for vector mode.

On 5/23/24 8:25 PM, Hongtao Liu wrote: CC for review. On Tue, May 21, 2024 at 1:12 PM liuhongt wrote: When mask is (1 << (prec - imm) - 1) which is used to clear upper bits of A, then it can be simplified to LSHIFTRT. i.e Simplify (and:v8hi (ashifrt:v8hi A 8) (const_vector 0xff x8))

[PATCH] Rearrange SLP nodes with duplicate statements. [PR98138]

This change adds a function that checks for SLP nodes with multiple occurrences of the same statement (e.g. {A, B, A, B, ...}) and tries to rearrange the node so that there are no duplicates. A vec_perm is then introduced to recreate the original ordering. These duplicates can appear due to how two

Re: [PATCH] ranger: Improve CLZ fold_range [PR115337]

OK by me... Andrew On 6/4/24 09:42, Jakub Jelinek wrote: Hi! cfn_ctz::fold_range includes special cases for the case where .CTZ has two arguments and so is well defined at zero, and the second argument is equal to prec or -1, but cfn_clz::fold_range does that only for the prec case. -1 is

Re: [PATCH-1] fwprop: Replace rtx_cost with insn_cost in try_fwprop_subst_pattern [PR113325]

On 1/25/24 6:16 PM, HAO CHEN GUI wrote: Hi, This patch replaces rtx_cost with insn_cost in forward propagation. In the PR, one constant vector should be propagated and replace a pseudo in a store insn if we know it's a duplicated constant vector. It reduces the insn cost but not rtx cost. I

Re: [PATCH] Fix PR c++/111106: missing ; causes internal compiler error

On 6/4/24 05:47, Simon Martin wrote: Hi Jason, Thanks for the review. On 31 May 2024, at 22:45, Jason Merrill wrote: On 5/30/24 07:31, Simon Martin wrote: We currently fail upon the following because an assert in dependent_type_p fails for f's parameter === cut here === consteval int id (in

Re: [PATCH] Don't simplify NAN/INF or out-of-range constant for FIX/UNSIGNED_FIX.

On 5/26/24 7:08 PM, liuhongt wrote: Update in V2: Guard constant folding for overflow value in fold_convert_const_int_from_real with flag_trapping_math. Add -fno-trapping-math to related testcases which warn for overflow in conversion from floating point to integer. Bootstrapped and regtested

[committed] libstdc++: Only define std::span::at for C++26 [PR115335]

Tested x86_64-linux. Pushed to trunk. Will backport to gcc-14 too. -- >8 -- In r14-5689-g1fa85dcf656e2f I added std::span::at and made the correct changes to the __cpp_lib_span macro (with tests for the correct value in C++20/23/26). But I didn't make the declaration of std::span::at actually dep

Re: [patch] libgomp: Enable USM for some nvptx devices

Andrew Stubbs wrote: PS: I would love to do some comparisons [...] Actually, I think testing only data transfer is fine for this, but we might like to try some different access patterns, besides straight linear copies. I have now tried it on my laptop with BabelStream,https://github.com/UoB-

[PATCH] [RFC] lower SLP load permutation to interleaving

The following emulates classical interleaving for SLP load permutes that we are unlikely handling natively. This is to handle cases where interleaving (or load/store-lanes) is the optimal choice for vectorizing even when we are doing that within SLP. An example would be void foo (int * __restric

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

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

[PATCH] Add missing space after seen_error in gcc/cp/pt.cc

I realized that I committed a change with a missing space after seen_error. This fixes it, as well as another occurrence in the same file. Apologies for the mistake - I'll commit this as obvious. gcc/cp/ChangeLog: * pt.cc (tsubst_expr): Add missing space after seen_error. (depend

[PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

The case in that PR used to ICE until commit f04dc89. This patch simply adds the case to the testsuite. Successfully tested on x86_64-pc-linux-gnu. PR c++/1033388 gcc/testsuite/ChangeLog: * g++.dg/parse/crash73.C: New test. --- gcc/testsuite/g++.dg/parse/crash73.C | 19 +++

Re: [Patch, rs6000, aarch64, middle-end] Add implementation for different targets for pair mem fusion

Hello Richard: On 03/06/24 9:28 pm, Ajit Agarwal wrote: > Hello Richard: > > On 03/06/24 8:24 pm, Richard Sandiford wrote: >> Ajit Agarwal writes: >>> Hello Richard: >>> >>> On 03/06/24 7:47 pm, Richard Sandiford wrote: Ajit Agarwal writes: > On 03/06/24 5:03 pm, Richard Sandiford wrot

Re: [PATCH v4] RISC-V: Introduce -mvector-strict-align.

On 5/28/24 1:19 PM, Robin Dapp wrote: Hi, this patch disables movmisalign by default and introduces the -mno-vector-strict-align option to override it and re-enable movmisalign. For now, generic-ooo is the only uarch that supports misaligned vector access. The patch also adds a check_effect

Re: [PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

On 6/4/24 11:54, Simon Martin wrote: The case in that PR used to ICE until commit f04dc89. Interesting, I don't remember expecting that patch to change behavior at all. BTW, it looks like your recent commits and emails have had non-conventional subject lines; see https://gcc.gnu.org/contri

nvptx offloading: 'GOMP_NVPTX_NATIVE_GPU_THREAD_STACK_SIZE' environment variable [PR97384, PR105274]

Hi! Any comments before I push to trunk branch the attached "nvptx offloading: 'GOMP_NVPTX_NATIVE_GPU_THREAD_STACK_SIZE' environment variable [PR97384, PR105274]"? While this happens to implement some baseline work for the PRs indicated, my original need for this is in upcoming libgomp Fortran t

Re: [PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

Hi Jason, On 4 Jun 2024, at 18:12, Jason Merrill wrote: > On 6/4/24 11:54, Simon Martin wrote: >> The case in that PR used to ICE until commit f04dc89. > > Interesting, I don't remember expecting that patch to change behavior > at all. This is the patch that git bisect identified. I have to admi

Clarify that 'gcc.dg/initpri3.c' is a LTO variant of 'gcc.dg/initpri1.c': 'gcc.dg/initpri1-lto.c' [PR46083] (was: PR lto/46083 (destructor priorities are wrong))

Hi! On 2011-01-10T13:56:06+0100, Richard Guenther wrote: > On Sun, 9 Jan 2011, Jan Hubicka wrote: >> On 2011-01-09T07:24:57-0800, "H.J. Lu" wrote: >> > On Sat, Jan 8, 2011 at 5:01 PM, Jan Hubicka wrote: >> > > the PR is about testsuite/initpri1.c failing with lto. >> > > >> > > I am not sure wh

Re: PATCH] AArch64: Fix cpu features initialization [PR115342]

Hi Richard, I've reworded the commit message a bit: The CPU features initialization code uses CPUID registers (rather than HWCAP). The equality comparisons it uses are incorrect: for example FEAT_SVE is not set if SVE2 is available. Using HWCAPs for these is both simpler and correct. The initi

Re: [PATCH v2 1/3] RISC-V: Add basic Zaamo and Zalrsc support

On 6/3/24 20:00, Kito Cheng wrote: Hi Patrick: One dumb question around Zaamo and Zalrsc, could we still got correct atomic semantic with only Zaamo or only Zalrsc? I guess Zalrsc only probably ok, but how about Zaamo only? This is a very valid question - AFAIK Zalrsc is always correct and Za

Re: PATCH] AArch64: Fix cpu features initialization [PR115342]

Wilco Dijkstra writes: > Hi Richard, > > I've reworded the commit message a bit: > > The CPU features initialization code uses CPUID registers (rather than > HWCAP). The equality comparisons it uses are incorrect: for example FEAT_SVE > is not set if SVE2 is available. Using HWCAPs for these is

[PATCH 1/4] Consolidate similar C/C++ test cases for 'constructor', 'destructor' function attributes with priority

gcc/testsuite/ * gcc.dg/initpri1.c: Integrate this... * g++.dg/special/initpri1.C: ..., and this... * c-c++-common/initpri1.c: ... here. * gcc.dg/initpri1-lto.c: Adjust. * gcc.dg/initpri2.c: Integrate this... * g++.dg/special/initpri2.C: ...,

More variants of C/C++ test cases for 'constructor', 'destructor' function attributes with priority

Hi! For my recent work on "nvptx target: Global constructor, destructor support, via nvptx-tools 'ld'", I needed more variants of C/C++ test cases for 'constructor', 'destructor' function attributes with priority: in particular, split into separate translation units, in combination with internal l

[PATCH 2/4] Add C++ testing for 'gcc.dg/initpri1-lto.c': 'c-c++-common/initpri1-lto.c'

Similar to TODO "Consolidate similar C/C++ test cases for 'constructor', 'destructor' function attributes with priority". gcc/testsuite/ * gcc.dg/initpri1-lto.c: Integrate this... * c-c++-common/initpri1-lto.c: ... here. --- gcc/testsuite/{gcc.dg => c-c++-common}/initpri1

[PATCH 3/4] Add 'c-c++-common/initpri1-split.c': 'c-c++-common/initpri1.c' split into separate translation units

gcc/testsuite/ * c-c++-common/initpri1.c: Split into... * c-c++-common/initpri1_part_c1.c: ... this, and... * c-c++-common/initpri1_part_c2.c: ... this, and... * c-c++-common/initpri1_part_c3.c: ... this, and... * c-c++-common/initpri1_part_cd4.c: ...

[PATCH 4/4] Add 'c-c++-common/initpri1{, -lto, -split}-static.c' as internal linkage variants

gcc/testsuite/ * c-c++-common/initpri1_part_c1.c: Consider 'CDTOR_LINKAGE'. * c-c++-common/initpri1_part_c2.c: Likewise. * c-c++-common/initpri1_part_c3.c: Likewise. * c-c++-common/initpri1_part_cd4.c: Likewise. * c-c++-common/initpri1_part_d1.c: Like

Re: [PATCH 50/52] pa: New hook implementation pa_c_mode_for_floating_type

Okay. Dave On 2024-06-02 11:01 p.m., Kewen Lin wrote: This is to add new port specific hook implementation pa_c_mode_for_floating_type, as we remove defines in defaults.h for {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE, this also defines them in pa.h but with PA_ prefix since we poison {FLOAT,{,LONG_}DOUB

[PATCH] [RFC] Prime path coverage in gcc/gcov

This patch adds prime path coverage to gcc/gcov. It is a bit rough in a few places, but I think all the main components are there and ready for some feedback while I keep working on the details. First a quick introduction to path coverage, before I explain a bit on the pieces of the patch and on wh

nvptx: Make 'nvptx_uniform_warp_check' fit for non-full-warp execution, via 'vote.all.pred' (was: nvptx: Make 'nvptx_uniform_warp_check' fit for non-full-warp execution (was: [committed][nvptx] Add un

Hi! On 2022-12-15T19:27:08+0100, I wrote: > First "a bit" of context; skip to "the proposed patch" if you'd like to > see just that. Here, I'm not again providing all the context; see the previous email if necessary. > My following discussion is about the implementation of > 'nvptx_uniform_warp_

Re: [PATCH] [RFC] lower SLP load permutation to interleaving

Richard Biener writes: > The following emulates classical interleaving for SLP load permutes > that we are unlikely handling natively. This is to handle cases > where interleaving (or load/store-lanes) is the optimal choice for > vectorizing even when we are doing that within SLP. An example > w

[PATCH v1 0/6] Add DLL import/export implementation to AArch64

Richard and Uros, could you please review the changes for v2? Additionally, we have detected an issue with GCC GC in winnt-dll.cc. The fix will be included in v2. >> -ix86_handle_selectany_attribute (tree *node, tree name, tree, int, >> +mingw_handle_selectany_attribute (tree *node, tree name, tr

Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading

> On Jun 4, 2024, at 03:43, Richard Biener wrote: > > On Mon, Jun 3, 2024 at 4:48 PM David Malcolm wrote: >> >> On Mon, 2024-06-03 at 08:29 +0200, Richard Biener wrote: >>> On Fri, May 31, 2024 at 11:23 PM Qing Zhao >>> wrote: > On May 23, 2024, at 07:46, Richard Biener

Re: [PATCH v2 1/3] RISC-V: Add basic Zaamo and Zalrsc support

On Tue, Jun 4, 2024 at 10:31 AM Patrick O'Neill wrote: > > On 6/3/24 20:00, Kito Cheng wrote: > > Hi Patrick: > > One dumb question around Zaamo and Zalrsc, could we still got correct > atomic semantic with only Zaamo or only Zalrsc? I guess Zalrsc only > probably ok, but how about Zaamo only? > >

"counted_by" and -fanalyzer (was Re: [PATCH v10 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.)

On Fri, 2024-05-31 at 13:11 +, Qing Zhao wrote: > > > > On May 31, 2024, at 08:58, Richard Biener > > wrote: > > > > On Thu, 30 May 2024, Qing Zhao wrote: > > > > > Including the following changes: > > > * The definition of the new internal function .ACCESS_WITH_SIZE > > >  in internal-fn.

Re: More variants of C/C++ test cases for 'constructor', 'destructor' function attributes with priority

On Jun 4, 2024, at 11:30 AM, Thomas Schwinge wrote: > > For my recent work on > "nvptx target: Global constructor, destructor support, via nvptx-tools 'ld'", > I needed more variants of C/C++ test cases for 'constructor', > 'destructor' function attributes with priority: in particular, split into

Re: "counted_by" and -fanalyzer (was Re: [PATCH v10 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.)

> On Jun 4, 2024, at 17:55, David Malcolm wrote: > > On Fri, 2024-05-31 at 13:11 +, Qing Zhao wrote: >> >> >>> On May 31, 2024, at 08:58, Richard Biener >>> wrote: >>> >>> On Thu, 30 May 2024, Qing Zhao wrote: >>> Including the following changes: * The definition of the new i

[COMMITTED] [PATCH v2] RISC-V: Add Zfbfmin extension

2024-06-04 04:30  Jeff Law wrote: > > > >On 6/1/24 1:45 AM, Xiao Zeng wrote: >> 1 In the previous patch, the libcall for BF16 was implemented: >> >> >> 2 Riscv provides Zfbfmin extension, which completes the "

RE: [PATCH v1] Internal-fn: Add new IFN mask_len_strided_load/store

> Sorry if we have discussed this last year already - is there anything wrong > with using a gather/scatter with a VEC_SERIES gimple/rtl def for the offset? Thanks for comments, it is quit a while since last discussion. Let me recall a little about it and keep you posted. Pan -Original Mess

RE: [PATCH v1] Internal-fn: Support new IFN SAT_SUB for unsigned scalar int

Kindly ping, almost the same but for subtract. Pan -Original Message- From: Li, Pan2 Sent: Tuesday, May 28, 2024 4:30 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; tamar.christ...@arm.com; richard.guent...@gmail.com; Li, Pan2 Subject: [PATCH v1] Intern

[PATCH 0/2] fix RISC-V zcmp popretz [PR113715]

The 1st patch adds a hook to allow post processing after epilogue inserted. The 2nd one implement the RISC-V hook to solve PR113715. Fei Gao (2): target hooks: allow post processing after epilogue inserted. [RISC-V]: fix zcmp popretz [PR113715]. gcc/config/riscv/riscv.cc |

[PATCH 2/2] [RISC-V]: fix zcmp popretz [PR113715].

Before this patch, when generating epilogue with zcmp enabled, the compiler tries to check if return value is 0. If so, the cm.popret insn in epilogue sequence and the return value a0=0 insn before the epilogue sequence will be replaced with a cm.popretz insn. However, if shrink wrap is active, the

[PATCH 1/2] target hooks: allow post processing after epilogue inserted.

Define TARGET_POST_EPILOGUE_PROC if you have additional processing after epilogue is inserted into a basic block. gcc/ChangeLog: * doc/tm.texi: Regenerate. * doc/tm.texi.in: Document TARGET_POST_EPILOGUE_PROC. * function.cc (thread_prologue_and_epilogue_insns): Allow

RE: [COMMITTED] testsuite: i386: Require ifunc support in gcc.target/i386/avx10_1-25.c etc.

Hi Rainer, I will also backport the patch to GCC14 since the original patch is also backported. Thank for your test on Solaris/x86! Thx, Haochen > -Original Message- > From: Rainer Orth > Sent: Tuesday, June 4, 2024 7:34 PM > To: gcc-patches@gcc.gnu.org > Cc: Jiang, Haochen > Subject:

Re: [PATCH-1] fwprop: Replace rtx_cost with insn_cost in try_fwprop_subst_pattern [PR113325]

Hi Jeff, 在 2024/6/4 22:14, Jeff Law 写道: > > > On 1/25/24 6:16 PM, HAO CHEN GUI wrote: >> Hi, >>    This patch replaces rtx_cost with insn_cost in forward propagation. >> In the PR, one constant vector should be propagated and replace a >> pseudo in a store insn if we know it's a duplicated const

[PATCH] haifa-sched: Avoid the fusion priority of the fused insn to affect the subsequent insn sequence.

When the insn 1 and 2, 3 and 4 can be fusioned, then there is the following sequence: ;;insn | ;; 1 | sp=sp-0x18 ;; + 2 | [sp+0x10]=ra ;; 3 | [sp+0x8]=s0 ;; 4 | [sp+0x0]=s1 The fusion priority of the insn 2, 3, and 4 are the same. According to the current algorithm, sinc

Ping [Patch-2, rs6000] Eliminate unnecessary byte swaps for duplicated constant vector store [PR113325]

Hi, Gently ping the patch. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643995.html Thanks Gui Haochen 在 2024/1/26 9:17, HAO CHEN GUI 写道: > Hi, > This patch creates an insn_and_split pattern which helps the duplicated > constant vector replace the source pseudo of store insn in fwp

[V2 PATCH] Simplify (AND (ASHIFTRT A imm) mask) to (LSHIFTRT A imm) for vector mode.

> Can you add a testcase for this? I don't mind if it's x86 specific and > does a bit of asm scanning. > > Also note that the context for this patch has changed, so it won't > automatically apply. So be extra careful when updating so that it goes > into the right place (all the more reason to hav

[PATCH v3 1/2] Factor out static_assert constexpr string extraction for reuse

The only semantics changes are slightly more vague error messages to generalize. gcc/cp/ChangeLog: * cp-tree.h (class cexpr_str): Add. * semantics.cc (finish_static_assert): Convert to use cexpr_str. (cexpr_str::type_check): Extract constexpr string code to here. (

v3 of constexpr asm patchkit

I addressed all the feedback and some other improvements: - Constant string extraction is now a class (cexpr_string) with cleaner interfaces - The error messages don't violate the NLS rules (needed some legacy test case adjustments) - Better error messages for missing brackets (but also needed

[PATCH v3 2/2] C++: Support constexpr strings for asm statements

Some programing styles use a lot of inline assembler, and it is common to use very complex preprocessor macros to generate the assembler strings for the asm statements. In C++ there would be a typesafe alternative using templates and constexpr to generate the assembler strings, but unfortunately th

Re: [PATCH v6 7/8] Give better error messages for musttail

[I slightly improve the patch covering a few more cases where tree-tailcall gives up, especially with -O1 and -Os. Here's the updated version.] Give better error messages for musttail When musttail is set, make tree-tailcall give error messages when it cannot handle a call. This avoids vagu

[pushed] wwwdocs: gcc-14: Make GCC 11-related link relative

This also better supports mirror sites (if still any). Gerald --- htdocs/gcc-14/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 7a5eb449..9a1b0c8a 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gc

pushed: wwwdocs: [PATCH] gcc-14/changes: Fix mislocated in RISC-V changes

--- Pushed as obvious. htdocs/gcc-14/changes.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 6447898e..7a5eb449 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -1218,9 +1218,9 @

[PATCH] s390: testsuite: Fix ifcvt-one-insn-bool.c

With the change of r15-787-g57e04879389f9c I forgot to also update this test. gcc/testsuite/ChangeLog: * gcc.target/s390/ifcvt-one-insn-bool.c: Fix loc. --- Ok for mainline? Ok for GCC 14 if the corresponding backport is also approved? gcc/testsuite/gcc.target/s390/ifcvt-one-insn-boo

Re: [PATCH v1 0/6] Add DLL import/export implementation to AArch64

On Tue, Jun 4, 2024 at 10:10 PM Evgeny Karpov wrote: > > Richard and Uros, could you please review the changes for v2? LGTM for the generic x86 part, OS-specific part (cygming) should also be reviewed by OS port maintainer (CC'd). Thanks, Uros. > Additionally, we have detected an issue with GCC

[pushed] libstdc++: Update gcc.gnu.org links in FAQ to https

libstdc++-v3: * doc/xml/faq.xml: Move gcc.gnu.org to https. * doc/html/faq.html: Regenerate. --- libstdc++-v3/doc/html/faq.html | 10 +- libstdc++-v3/doc/xml/faq.xml | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/libstdc++-v3/doc/html/fa

Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

> On 12/20/23 4:17 AM, Jin Ma wrote: > > We don't have SI -> BF library functions, use SI -> SF -> BF > > instead. Although this can also be implemented in a target > > machine description, it is more appropriate to move > > into target independent code. > > > > gcc/ChangeLog: > > > >  * optabs.c

[PATCH 1/4] Relax COND_EXPR reduction vectorization SLP restriction

Allow one-lane SLP but for the case where we need to swap the arms. * tree-vect-stmts.cc (vectorizable_condition): Allow single-lane SLP, but not when we need to swap then and else clause. --- gcc/tree-vect-stmts.cc | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-

[PATCH 2/4] Allow single-lane COND_REDUCTION vectorization

The following enables single-lane COND_REDUCTION vectorization. * tree-vect-loop.cc (vect_create_epilog_for_reduction): Adjust for single-lane COND_REDUCTION SLP vectorization. (vectorizable_reduction): Likewise. (vect_transform_cycle_phi): Likewise. --- gcc/tree-v

[PATCH 3/4] Add double reduction support for SLP vectorization

The following makes double reduction vectorization work when using (single-lane) SLP vectorization. * tree-vect-loop.cc (vect_analyze_scalar_cycles_1): Queue double reductions in LOOP_VINFO_REDUCTIONS. (vect_create_epilog_for_reduction): Remove asserts disabling SLP

[PATCH 4/4] RISC-V: Allow single-lane SLP in-order reductions

The single-lane case isn't different from non-SLP, no re-association implied. But the transform stage cannot handle a conditional reduction op which isn't checked during analysis - this makes it work, exercised with a single-lane non-reduction-chain by gcc.target/i386/pr112464.c * tree-ve

Re: pushed: wwwdocs: [PATCH] gcc-14/changes: Fix mislocated in RISC-V changes

Ohh, thanks for fixing that! On Wed, Jun 5, 2024 at 1:16 PM Xi Ruoyao wrote: > > --- > > Pushed as obvious. > > htdocs/gcc-14/changes.html | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 6447898e..7a5eb4

Re: Clarify that 'gcc.dg/initpri3.c' is a LTO variant of 'gcc.dg/initpri1.c': 'gcc.dg/initpri1-lto.c' [PR46083] (was: PR lto/46083 (destructor priorities are wrong))

On Tue, 4 Jun 2024, Thomas Schwinge wrote: > Hi! > > On 2011-01-10T13:56:06+0100, Richard Guenther wrote: > > On Sun, 9 Jan 2011, Jan Hubicka wrote: > >> On 2011-01-09T07:24:57-0800, "H.J. Lu" wrote: > >> > On Sat, Jan 8, 2011 at 5:01 PM, Jan Hubicka wrote: > >> > > the PR is about testsuite/i

Re: [PATCH 0/2] fix RISC-V zcmp popretz [PR113715]

Thanks for fixing this issue, and I am wondering doest it possible to fix that without introduce target hook? I ask that because...GCC 14 also has this bug, but I am not sure it's OK to introduce new target hook for release branch? or would you suggest we just revert patch to fix that on GCC 14? O

Re: [PATCH] c: Fix up pointer types to may_alias structures [PR114493]

Am Dienstag, dem 04.06.2024 um 08:33 +0200 schrieb Jakub Jelinek: > Hi! > > The following testcase ICEs in ipa-free-lang, because the > fld_incomplete_type_of > gcc_assert (TYPE_CANONICAL (t2) != t2 > && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE > (t))); > a