Re: [PATCH v4] i386: Allow -mlarge-data-threshold with -mcmodel=large

On Tue, Aug 1, 2023 at 12:51 PM Fangrui Song wrote: > > When using -mcmodel=medium, large data objects larger than the > -mlarge-data-threshold threshold are placed into large data sections > (.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place > .l* sections into separate outp

Re: [OpenMP/offloading][RFC] How to handle target/device-specifics with C pre-processor (in general, inside 'omp declare variant')

On Mon, Aug 21, 2023 at 6:23 PM Tobias Burnus wrote: > > RFC – and idea how to handle this best in GCC? See the two examples > below for what we would like to support. > > * * * > > In GCC, we handle OpenMP (and OpenACC) by parsing the input file once, > produce an internal representation (in LTO

Re: Re: [PATCH] RISCV: Fix PR111074 [GCC13 BUG]

Committed, thanks all. -- Li Xu >The test case is too complicated and I can't simplify it, so no test case is >added. > >-- >Li Xu >>From: xuli >> >>This patch fixes this issue happens on GCC-13. >>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111074 >> >>This patch should

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

> What about conditional zero_extension, sign_extension, > float_extension, ...etc? > > We have discussed this, we can have some many conditional situations > that can be supported by either match.pd or rtl backend combine > pass. > > IMHO, it will be too many optabs/internal fns if we support al

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 5:20 AM Jiang, Haochen wrote: > > > -Original Message- > > From: ZiNgA BuRgA > > Sent: Monday, August 21, 2023 5:27 PM > > To: Richard Biener ; Hongtao Liu > > > > Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org > > Subject: Re: Intel AVX10.1 Compiler Design and Supp

[PATCH] c++: Implement C++26 P2169R4 - Placeholder variables with no name [PR110349]

Hi! The following patch implements the C++26 P2169R4 paper. As written in the PR, the patch expects that: 1) https://eel.is/c++draft/expr.prim.lambda.capture#2 "Ignoring appearances in initializers of init-captures, an identifier or this shall not appear more than once in a lambda-capture."

Re: Loop-ch improvements, part 3

On Tue, 22 Aug 2023, Hongtao Liu wrote: > On Mon, Jul 17, 2023 at 5:18?PM Richard Biener via Gcc-patches > wrote: > > > > On Fri, 14 Jul 2023, Jan Hubicka wrote: > > > > > Hi, > > > loop-ch currently does analysis using ranger for all loops to identify > > > candidates and then follows by phase w

Re: Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

Yes, I agree long-term we want every-thing be optimized as early as possible. However, IMHO, it's impossible we can support every conditional patterns in the middle-end (match.pd). It's a really big number. For example, for sign_extend conversion, we have vsext.vf2 (vector SI -> vector DI),...

[PATCH] c++: Fix up mangling of function/block scope static structured bindings [PR111069]

Hi! As can be seen on the testcase, we weren't correctly mangling static/thread_local structured bindings (C++20 feature) at function/block scope. The following patch fixes that by using what write_local_name does for those cases (note, structured binding mandling doesn't use the standard path be

[PATCH] doc: Remove obsolete sentence about _Float* not being supported in C++ [PR106652]

Hi! As mentioned in the PR, these types are supported in C++ since GCC 13, so we shouldn't confuse users. Ok for trunk? 2023-08-22 Jakub Jelinek PR c++/106652 * doc/extend.texi (_Float): Drop obsolete sentence that the types aren't supported in C++. --- gcc/doc/exten

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

Revised patch. I does the job on darwin, can you check that it still tests the functions on Linux? And if so, OK to commit? FX 0001-Testsuite-DWARF2-adjust-regexp-to-match-darwin-outpu.patch Description: Binary data

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Tue, Aug 22, 2023 at 10:16:37AM +0200, FX Coudert wrote: > Revised patch. I does the job on darwin, can you check that it still tests > the functions on Linux? Seems the attached patch doesn't match what was discussed in this thread. And for that DWARF patch, I'd like to see what different out

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

> Revised patch. I does the job on darwin, can you check that it still tests > the functions on Linux? > And if so, OK to commit? With the correct file, sorry. 0001-libgomp-testsuite-Do-not-call-nonstandard-functions.patch Description: Binary data

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches wrote: > I think internally we should have conditional 512bit support work across > AVX512 and AVX10. > > I also think it makes sense to _internally_ have AVX10.1 (10.1!) just > enable the respective AVX512 features. AVX10.2

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 10:34 AM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches > wrote: > > I think internally we should have conditional 512bit support work across > > AVX512 and AVX10. > > > > I also think it makes sense to _internally_ have A

Re: [PATCH 4/12] Middle-end _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek wrote: > Hi! > > The following patch introduces the middle-end part of the _BitInt > support, a new BITINT_TYPE, handling it where needed, except the lowering > pass and sanitizer support. This is OK. Thanks, Richard. > 2023-08-09 Jakub Jelinek > > P

Re: [OpenMP/offloading][RFC] How to handle target/device-specifics with C pre-processor (in general, inside 'omp declare variant')

On 22.08.23 09:25, Richard Biener wrote: On Mon, Aug 21, 2023 at 6:23 PM Tobias Burnus wrote: ... Err, so the OMP standard doesn't put any constraints on what to allow inside the variants? Is declare variant always at the toplevel? Actually, the OpenMP specification only states the followin

[PATCH] vect: Replace DR_GROUP_STORE_COUNT with DR_GROUP_LAST_ELEMENT

Hi, Now we use DR_GROUP_STORE_COUNT to record how many stores in a group have been transformed and only do the actual transform when encountering the last one. I'm making patches to move costing next to the transform code, it's awkward to use this DR_GROUP_STORE_COUNT for both costing and transfo

[PATCH 1/3] vect: Remove some manual release in vectorizable_store

Hi, To avoid some duplicates in some follow-up patches on function vectorizable_store, this patch is to adjust some existing vec with auto_vec and remove some manual release invocation. Also refactor a bit and remove some useless codes. Bootstrapped and regtested on x86_64-redhat-linux, aarch64-

[PATCH 2/3] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

Hi, Like commit r14-3214 which moves the handlings on memory access type VMAT_LOAD_STORE_LANES in vectorizable_load final loop nest, this one is to deal with the function vectorizable_store. Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it

[PATCH 3/3] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

Hi, Like r14-3317 which moves the handlings on memory access type VMAT_GATHER_SCATTER in vectorizable_load final loop nest, this one is to deal with vectorizable_store side. Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it ok for trunk? BR

RE: Intel AVX10.1 Compiler Design and Support

> -Original Message- > From: Richard Biener > Sent: Tuesday, August 22, 2023 4:36 PM > To: Jakub Jelinek > Cc: Jiang, Haochen ; ZiNgA BuRgA > ; Hongtao Liu ; gcc- > patc...@gcc.gnu.org > Subject: Re: Intel AVX10.1 Compiler Design and Support > > On Tue, Aug 22, 2023 at 10:34 AM Jakub Jel

[PATCH] tree-optimization/94864 - vector insert of vector extract simplification

The PRs ask for optimizing of _1 = BIT_FIELD_REF ; result_4 = BIT_INSERT_EXPR ; to a vector permutation. The following implements this as match.pd pattern, improving code generation on x86_64. On the RTL level we face the issue that backend patterns inconsistently use vec_merge and vec_sele

Re: [OpenMP/offloading][RFC] How to handle target/device-specifics with C pre-processor (in general, inside 'omp declare variant')

On Tue, Aug 22, 2023 at 10:43:54AM +0200, Tobias Burnus wrote: > On 22.08.23 09:25, Richard Biener wrote: > > On Mon, Aug 21, 2023 at 6:23 PM Tobias Burnus > > wrote: > > > ... > > Err, so the OMP standard doesn't put any constraints on what to allow > > inside the > > variants? Is declare vari

Re: [PATCH] tree-optimization/94864 - vector insert of vector extract simplification

On Tue, Aug 22, 2023 at 5:05 PM Richard Biener via Gcc-patches wrote: > > The PRs ask for optimizing of > > _1 = BIT_FIELD_REF ; > result_4 = BIT_INSERT_EXPR ; > > to a vector permutation. The following implements this as > match.pd pattern, improving code generation on x86_64. > > On the RTL

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 10:53 AM Jiang, Haochen wrote: > > > -Original Message- > > From: Richard Biener > > Sent: Tuesday, August 22, 2023 4:36 PM > > To: Jakub Jelinek > > Cc: Jiang, Haochen ; ZiNgA BuRgA > > ; Hongtao Liu ; gcc- > > patc...@gcc.gnu.org > > Subject: Re: Intel AVX10.1 C

[patch] OpenMP: Handle 'all' as category in defaultmap

I stumbled over this when compiling the defaultmap files of the OpenMP example document (upcoming version). Seemingly, an 'all' was sneaked in when the syntax representation was changed (as alias for not specifying a category). I wonder which intended or nonintended changes are still hiding and

RE: [PATCH] arm: [MVE intrinsics] fix binary_acca_int32 and binary_acca_int64 shapes

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Monday, August 14, 2023 7:01 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH] arm: [MVE intrinsics] fix binary_acca_int32 and > binary_

RE: [PATCH] arm: [MVE intrinsics] Remove dead check for float type in parse_element_type

> -Original Message- > From: Christophe Lyon > Sent: Monday, August 14, 2023 7:10 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH] arm: [MVE intrinsics] Remove dead check for float type in > parse_elem

RE: [PATCH 1/9] arm: [MVE intrinsics] factorize vmullbq vmulltq

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Monday, August 14, 2023 7:34 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 1/9] arm: [MVE intrinsics] factorize vmullbq vmulltq > >

[patch] libgomp.c/simd-math-1.c: Test scalb{, l}n{, f} and un-XFAIL for non-nvptx/amdgcn

As mentioned in the 'libgomp, testsuite: Do not call nonstandard functions on darwin' thread: * scalb was deprecated then deleted in POSIX in favor of scalbn{,f} and scalbln{,f} which take an int or long, respectively, instead of double for the 'exp' argument of 'x * FLT_RADIX ** exp'. It

[PATCH 00/11] aarch64 GCS preliminary patches

I'm working on Guarded Control Stack support for aarch64 and have a set of patches that are needed for GCS but seem useful without it so makes sense to review them separately from the rest of the GCS work. GCS support will depend on the linux ABI that is under discussion at https://lore.kernel.org

[PATCH 01/11] aarch64: AARCH64_ISA_RCPC was defined twice

gcc/ChangeLog: * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): Remove dup. --- gcc/config/aarch64/aarch64.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h index 2b0fc97bb71..c783cb96c48 100644 --- a/gcc/config/aarch64/aarch64.

[PATCH 06/11] aarch64: Fix pac-ret eh_return tests

This is needed since eh_return no longer prevents pac-ret in the normal return path. gcc/testsuite/ChangeLog: * gcc.target/aarch64/return_address_sign_1.c: Move func4 to ... * gcc.target/aarch64/return_address_sign_2.c: ... here and fix the scan asm check. * gcc.ta

[PATCH 07/11] aarch64: Disable branch-protection for pcs tests

The tests manipulate the return address in abitest-2.h and thus not compatible with -mbranch-protection=pac-ret+leaf or -mbranch-protection=gcs. gcc/testsuite/ChangeLog: * gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection. * gcc.target/aarch64/aapcs64/func-ret-2.c

[PATCH 08/11] aarch64,arm: Remove accepted_branch_protection_string

On aarch64 this caused ICE with pragma push_options since commit ae54c1b09963779c5c3914782324ff48af32e2f1 Author: Wilco Dijkstra CommitDate: 2022-06-01 18:13:57 +0100 AArch64: Cleanup option processing code The failure is at pop_options: internal compiler error: ‘global_options’ ar

[PATCH 03/11] aarch64: Use br instead of ret for eh_return

The expected way to handle eh_return is to pass the stack adjustment offset and landing pad address via EH_RETURN_STACKADJ_RTX EH_RETURN_HANDLER_RTX to the epilogue that is shared between normal return paths and the eh_return paths. EH_RETURN_HANDLER_RTX is the stack slot of the return addre

[PATCH 02/11] Handle epilogues that contain jumps

From: Richard Sandiford The prologue/epilogue pass allows the prologue sequence to contain jumps. The sequence is then partitioned into basic blocks using find_many_sub_basic_blocks. This patch treats epilogues in the same way. It's needed for a follow-on aarch64 patch that adds conditional co

[PATCH 09/11] aarch64,arm: Fix branch-protection= parsing

Refactor the parsing to have a single API and fix a few parsing issues: - Different handling of "bti+none" and "none+bti": these should be rejected because "none" can only appear alone. - Accepted empty strings such as "bti++pac-ret" or "bti+", this bug was caused by using strtok_r. - Memory

[PATCH 04/11] aarch64: Do not force a stack frame for EH returns

EH returns no longer rely on clobbering the return address on the stack so forcing a stack frame is not necessary. This does not actually change the code gen for the unwinder since there are calls before the EH return. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_needs_frame_chain

[PATCH 10/11] aarch64: Fix branch-protection error message tests

Update tests for the new branch-protection parser errors. gcc/testsuite/ChangeLog: * gcc.target/aarch64/branch-protection-attr.c: Update. * gcc.target/aarch64/branch-protection-option.c: Update. --- gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c | 6 +++--- gcc/tests

[PATCH 05/11] aarch64: Add eh_return compile tests

gcc/testsuite/ChangeLog: * gcc.target/aarch64/eh_return-2.c: New test. * gcc.target/aarch64/eh_return-3.c: New test. --- gcc/testsuite/gcc.target/aarch64/eh_return-2.c | 9 + gcc/testsuite/gcc.target/aarch64/eh_return-3.c | 14 ++ 2 files changed, 23 insertion

[PATCH 11/11] aarch64,arm: Move branch-protection data to targets

The branch-protection types are target specific, not the same on arm and aarch64. This currently affects pac-ret+b-key, but there will be a new type on aarch64 that is not relevant for arm. gcc/ChangeLog: * config/aarch64/aarch64-opts.h (enum aarch64_key_type): Rename to ... (enu

[PATCH] VECT: Add LEN_FOLD_EXTRACT_LAST pattern

Hi, Richard and Richi. This is the last autovec pattern I want to add for RVV (length loop control). This patch is supposed to handled this following case: int __attribute__ ((noinline, noclone)) condition_reduction (int *a, int min_v, int n) { int last = 66; /* High start value. */ for (i

Re: [PATCH 02/11] Handle epilogues that contain jumps

On Tue, Aug 22, 2023 at 12:42 PM Szabolcs Nagy via Gcc-patches wrote: > > From: Richard Sandiford > > The prologue/epilogue pass allows the prologue sequence > to contain jumps. The sequence is then partitioned into > basic blocks using find_many_sub_basic_blocks. > > This patch treats epilogues

Re: [PATCH] VECT: Add LEN_FOLD_EXTRACT_LAST pattern

On Tue, 22 Aug 2023, Juzhe-Zhong wrote: > Hi, Richard and Richi. > > This is the last autovec pattern I want to add for RVV (length loop control). > > This patch is supposed to handled this following case: > > int __attribute__ ((noinline, noclone)) > condition_reduction (int *a, int min_v, int

Re: [PATCH 7/12] ubsan: _BitInt -fsanitize=undefined support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek wrote: > Hi! > > The following patch introduces some -fsanitize=undefined support for _BitInt, > but some of the diagnostics is limited by lack of proper support in the > library. > I've filed https://github.com/llvm/llvm-project/issues/64100 to request > proper

[PATCH 14/12] libgcc _BitInt helper documentation [PR102989]

On Mon, Aug 21, 2023 at 05:32:04PM +, Joseph Myers wrote: > I think the libgcc functions (i.e. those exported by libgcc, to which > references are generated by the compiler) need documenting in libgcc.texi. > Internal functions or macros in the libgcc patch need appropriate comments > speci

[PATCH] rtl: Forward declare rtx_code

Now that we require C++ 11, we can safely forward declare rtx_code so that we can use it in target hooks. gcc/ChangeLog * coretypes.h (rtx_code): Add forward declaration. * rtl.h (rtx_code): Make compatible with forward declaration. --- gcc/coretypes.h | 4 gcc/rtl.h |

Re: Loop-ch improvements, part 3

> > We seem to peel one iteration for no good reason. The loop is > a do-while loop already. The key is we see the first iteration > exit condition is known not taken and then: > > Registering value_relation (path_oracle) (iter.24_6 > iter.24_5) (root: > bb2) > Stmt is static (constant in

Re: [PATCH] vect: Replace DR_GROUP_STORE_COUNT with DR_GROUP_LAST_ELEMENT

On Tue, Aug 22, 2023 at 10:44 AM Kewen.Lin wrote: > > Hi, > > Now we use DR_GROUP_STORE_COUNT to record how many stores > in a group have been transformed and only do the actual > transform when encountering the last one. I'm making > patches to move costing next to the transform code, it's > awk

Re: [PATCH 1/3] vect: Remove some manual release in vectorizable_store

On Tue, Aug 22, 2023 at 10:45 AM Kewen.Lin wrote: > > Hi, > > To avoid some duplicates in some follow-up patches on > function vectorizable_store, this patch is to adjust some > existing vec with auto_vec and remove some manual release > invocation. Also refactor a bit and remove some useless > c

[PATCH v1] libffi: Backport of LoongArch support for libffi.

This is a backport of , and contains modifications to commit 5a4774cd4d, as well as the LoongArch schema portion of commit ee22ecbd11. This is needed for libgo. libffi/ChangeLog: * configure.host: Add LoongArch support. * Makefi

Re: [PATCH V2 0/5] OpenMP: support for imperfectly-nested loops

On Sun, Jul 23, 2023 at 04:15:16PM -0600, Sandra Loosemore wrote: > Here is the latest version of my imperfectly-nested loops patches. > Compared to the initial version I'd posted in April > > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617103.html > > this version includes many minor co

Re: [PATCH V2 1/5] OpenMP: Add OMP_STRUCTURED_BLOCK and GIMPLE_OMP_STRUCTURED_BLOCK.

On Sun, Jul 23, 2023 at 04:15:17PM -0600, Sandra Loosemore wrote: > In order to detect invalid jumps in and out of intervening code in > imperfectly-nested loops, the front ends need to insert some sort of > marker to identify the structured block sequences that they push into > the inner body of t

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 4:34 PM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches > wrote: > > I think internally we should have conditional 512bit support work across > > AVX512 and AVX10. > > > > I also think it makes sense to _internally_ have AV

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > > name to represent whether the effective ISA set allows 512-bit vectors or > > not. I think -mavx10.1 -mno-avx512cd should be fine. And, -mavx10.1-256 > > o

[PATCH] Simplify intereaved store vectorization processing

When doing interleaving we perform code generation when visiting the last store of a chain. We keep track of this via DR_GROUP_STORE_COUNT, the following localizes this to the caller of vectorizable_store, also avoing redundant non-processing of the other stores. Bootstrapped and tested on x86_64

Re: [PATCH v1] libffi: Backport of LoongArch support for libffi.

On Tue, 22 Aug 2023, Lulu Cheng wrote: > This is a backport of , > and contains modifications to commit 5a4774cd4d, as well as the LoongArch > schema portion of commit ee22ecbd11. This is needed for libgo. OK. > > libffi/ChangeLog: > >

Re: [PATCH V2 2/5] OpenMP: C front end support for imperfectly-nested loops

> New common C/C++ testcases are in a separate patch. > > gcc/c-family/ChangeLog > * c-common.h (c_omp_check_loop_binding_exprs): Declare. > * c-omp.cc: Include tree-iterator.h. > (find_binding_in_body): New. > (check_loop_binding_expr_r): New. > (LOCATION_OR): New. >

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > > > name to represent whether the effective ISA set allows 512-bit vectors or > > > not. I think -

Re: [PATCH v1] libffi: Backport of LoongArch support for libffi.

On Tue, 2023-08-22 at 20:42 +0800, Lulu Cheng wrote: > This is a backport of , > and contains modifications to commit 5a4774cd4d, as well as the LoongArch > schema portion of commit ee22ecbd11. This is needed for libgo. > > > libffi/ChangeLog:

Re: [PATCH 2/3] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

On Tue, Aug 22, 2023 at 10:49 AM Kewen.Lin wrote: > > Hi, > > Like commit r14-3214 which moves the handlings on memory > access type VMAT_LOAD_STORE_LANES in vectorizable_load > final loop nest, this one is to deal with the function > vectorizable_store. > > Bootstrapped and regtested on x86_64-re

Re: [PATCH 3/3] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

On Tue, Aug 22, 2023 at 10:52 AM Kewen.Lin wrote: > > Hi, > > Like r14-3317 which moves the handlings on memory access > type VMAT_GATHER_SCATTER in vectorizable_load final loop > nest, this one is to deal with vectorizable_store side. > > Bootstrapped and regtested on x86_64-redhat-linux, > aarch

Re: [PATCH V2 3/5] OpenMP: C++ support for imperfectly-nested loops

On Sun, Jul 23, 2023 at 04:15:19PM -0600, Sandra Loosemore wrote: > OpenMP 5.0 removed the restriction that multiple collapsed loops must > be perfectly nested, allowing "intervening code" (including nested > BLOCKs) before or after each nested loop. In GCC this code is moved > into the inner loop

Re: [PATCH V2 4/5] OpenMP: New C/C++ testcases for imperfectly nested loops.

On Sun, Jul 23, 2023 at 04:15:20PM -0600, Sandra Loosemore wrote: > gcc/testsuite/ChangeLog > * c-c++-common/gomp/imperfect-attributes.c: New. > * c-c++-common/gomp/imperfect-badloops.c: New. > * c-c++-common/gomp/imperfect-blocks.c: New. > * c-c++-common/gomp/imperfect-exte

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 9:24 PM Richard Biener wrote: > > On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote: > > > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > > Agreed. And I still think -mevex512 vs. -mno-evex512 is the best option > > > > name to represent whether th

Re: [PATCH V2 5/5] OpenMP: Fortran support for imperfectly-nested loops

On Sun, Jul 23, 2023 at 04:15:21PM -0600, Sandra Loosemore wrote: > OpenMP 5.0 removed the restriction that multiple collapsed loops must > be perfectly nested, allowing "intervening code" (including nested > BLOCKs) before or after each nested loop. In GCC this code is moved > into the inner loop

Re: [PATCH] doc: Remove obsolete sentence about _Float* not being supported in C++ [PR106652]

On 8/22/23 02:15, Jakub Jelinek via Gcc-patches wrote: Hi! As mentioned in the PR, these types are supported in C++ since GCC 13, so we shouldn't confuse users. Ok for trunk? 2023-08-22 Jakub Jelinek PR c++/106652 * doc/extend.texi (_Float): Drop obsolete sentence that t

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote: > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit > evex instruction patterns. Why? Internally for md etc. purposes, we should have the current TARGET_AVX512* etc. ISA flags, plus one new one, whatever we call it (TA

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote: Yes, I agree long-term we want every-thing be optimized as early as possible. However, IMHO, it's impossible we can support every conditional patterns in the middle-end (match.pd). It's a really big number. For example, for sign_extend convers

Re: [committed] i386: Fix grammar typo in diagnostic

On Mon, 7 Aug 2023, Marek Polacek via Gcc-patches wrote: >> Less obvious (to me) is whether it's correct to say "GCC V13" here. I >> don't think we refer to a version that way anywhere else, do we? >> >> Would "since GCC 13.1.0" be better? > x86_field_alignment uses > > inform (inpu

RE: [PATCH] VECT: Add LEN_FOLD_EXTRACT_LAST pattern

Committed as passed both the regression and bootstrap tests in x86, thanks Richard. Pan -Original Message- From: Gcc-patches On Behalf Of Richard Biener via Gcc-patches Sent: Tuesday, August 22, 2023 7:08 PM To: Juzhe-Zhong Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com Subjec

Re: Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

>> It's certainly got the potential to get out of hand. And it's not just >> the vectorizer operations. I know of an architecture that can execute >> most of its ALU and loads/stores conditionally (not predication, but >> actual conditional ops) like target = (x COND Y) ? a << b ; a) Do you mea

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 9:54 PM Jakub Jelinek wrote: > > On Tue, Aug 22, 2023 at 09:35:44PM +0800, Hongtao Liu wrote: > > Ok, then we can't avoid TARGET_AVX10_1 in those existing 256/128-bit > > evex instruction patterns. > > Why? > Internally for md etc. purposes, we should have the current > TAR

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 9:35 PM Hongtao Liu wrote: > > On Tue, Aug 22, 2023 at 9:24 PM Richard Biener > wrote: > > > > On Tue, Aug 22, 2023 at 3:16 PM Jakub Jelinek wrote: > > > > > > On Tue, Aug 22, 2023 at 09:02:29PM +0800, Hongtao Liu wrote: > > > > > Agreed. And I still think -mevex512 vs.

Re: [PATCH] RISC-V: Add Types to Un-Typed Sync Instructions:

On 8/21/2023 2:41 PM, Jeff Law via Gcc-patches wrote: On 8/21/23 10:51, Edwin Lu wrote: @@ -77,4 +78,4 @@ (define_insn "atomic_store_ztso"     return "s\t%z1,%0";     }     [(set_attr "type" "atomic") -   (set (attr "length") (const_int 8))]) \ No newline at end of file +   (set (attr "len

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 10:35:55PM +0800, Hongtao Liu wrote: > Let's assume there's no detla now, AVX10.1-512 is equal to > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG, VPOPCNTDQ} > > other stuff. > > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET* would be > > lik

Re: [PATCH] libgccjit: Add support for `restrict` attribute on function parameters

Since the tests in the PR for rustc_codegen_gcc (https://github.com/rust-lang/rustc_codegen_gcc/pull/312) currently fails, let's wait a bit before merging the patch, in case it would need some fixes. On Thu, 2023-08-17 at 20:09 +0200, Guillaume Gomez via Jit wrote: > Quick question: do you plan to

Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

It's really great improvement, it's drop some state like HARD_EMPTY and DIRTY_WITH_KILLED_AVL which make this algorithm more easy to understand! also this also fundamentally improved the phase 3, although one concern is the time complexity might be come more higher order, (and it's already high eno

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Tue, Aug 22, 2023 at 10:25:51AM +0200, FX Coudert wrote: > > Revised patch. I does the job on darwin, can you check that it still tests > > the functions on Linux? > > And if so, OK to commit? > > With the correct file, sorry. Seems to work for me, I see ... -DNONSTDFUNC=1 ... on the test's c

[PATCH][committed] RISC-V: Add multiarch support on riscv-linux-gnu

This adds multiarch support to the RISC-V port so that bootstraps work with Debian out-of-the-box. Without this patch the stage1 compiler is unable to find headers/libraries when building the stage1 runtime. This is functionally (and possibly textually) equivalent to Debian's fix for the sa

[PATCH] RISC-V: output Autovec params explicitly in --help ...

... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-lmul Signed-off-by: Vineet Gupta --- gcc/config/riscv/riscv.opt | 4 ++-- 1 file changed, 2 insertions(+), 2 dele

Re: [PATCH v4] c++: extend cold, hot attributes to classes

On 8/15/23 09:41, Javier Martinez wrote: On Mon, Aug 14, 2023 at 8:32 PM Jason Merrill > wrote: > I think you also want to check for ATTR_FLAG_TYPE_IN_PLACE. > [...] > > +  propagate_class_warmth_attribute (t); > Maybe call this in check_bases_and_members instead? Ye

Re: [PATCH] RISC-V: output Autovec params explicitly in --help ...

On 8/22/23 11:40, Vineet Gupta wrote: ... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-lmul OK jeff

Re: [PATCH][committed] RISC-V: Add multiarch support on riscv-linux-gnu

On Tue, 22 Aug 2023 10:39:38 PDT (-0700), Jeff Law wrote: This adds multiarch support to the RISC-V port so that bootstraps work with Debian out-of-the-box. Without this patch the stage1 compiler is unable to find headers/libraries when building the stage1 runtime. This is functionally (and po

Re: [PATCH] RISC-V: output Autovec params explicitly in --help ...

On Tue, 22 Aug 2023 10:59:35 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On 8/22/23 11:40, Vineet Gupta wrote: ... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-

[Committed] RISC-V: output Autovec params explicitly in --help ...

... otherwise user has no clue what -param to actually change gcc/ChangeLog: * config/riscv/riscv.opt: Add --param names riscv-autovec-preference and riscv-autovec-lmul Signed-off-by: Vineet Gupta --- gcc/config/riscv/riscv.opt | 4 ++-- 1 file changed, 2 insertions(+), 2 deleti

Re: [PATCH] RISC-V: output Autovec params explicitly in --help ...

On 8/22/23 11:07, Palmer Dabbelt wrote: We should probably put them in invoke.texi as well (and anything else we're missing that's been added recently). Looks like I'd pushed the patch already. A whole bunch of them are missing, so guess that can happen seperately. -Vineet

[pushed 1/2] c++: constrained hidden friends [PR109751]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all. We

[pushed 2/2] c++: maybe_substitute_reqs_for fix

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While working on PR109751 I found that maybe_substitute_reqs_for was doing the wrong thing for a non-template friend, substituting in the template args of the scope's original template rather than those of the instantiation. This didn't end

Re: [PATCH V2 2/5] OpenMP: C front end support for imperfectly-nested loops

On 8/22/23 07:23, Jakub Jelinek wrote: diff --git a/gcc/testsuite/c-c++-common/goacc/collapse-1.c b/gcc/testsuite/c-c++-common/goacc/collapse-1.c index 11b14383983..0feac8f8ddb 100644 --- a/gcc/testsuite/c-c++-common/goacc/collapse-1.c +++ b/gcc/testsuite/c-c++-common/goacc/collapse-1.c @@ -8,

Re: [PATCH][committed] RISC-V: Add multiarch support on riscv-linux-gnu

On 8/22/23 12:03, Palmer Dabbelt wrote: On Tue, 22 Aug 2023 10:39:38 PDT (-0700), Jeff Law wrote: The docs seem to suggest that we should have a multarch-compatible MULTILIB_OSDIRNAMES as we support both multilib and multiarch:    @code{MULTIARCH_DIRNAME} is not used for configurations

Re: [PATCH v10 3/5] c++: Implement __is_function built-in trait

On Wed, 12 Jul 2023, Ken Matsui via Libstdc++ wrote: > This patch implements built-in trait for std::is_function. > > gcc/cp/ChangeLog: > > * cp-trait.def: Define __is_function. > * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION. > * semantics.cc (trait_expr_value

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

Hi Lehua, no concerns here, just tiny remarks but in general LGTM as is. > +(define_insn_and_split "*copysign_neg" > + [(set (match_operand:VF 0 "register_operand") > +(neg:VF > + (unspec:VF [ > +(match_operand:VF 1 "register_operand") > +(match_operand:V

[pushed] analyzer: reimplement kf_strlen [PR105899]

Reimplement kf_strlen in terms of the new string scanning implementation, sharing strlen's implementation with __analyzer_get_strlen. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-3391-g3242fb533d48ab. gcc/analyzer/ChangeLog: PR analyzer/105899

Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Mon, Aug 21, 2023 at 8:25 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Jakub Jelinek (12): > > expr: Small optimization [PR102989] > > lto-streamer-in: Adjust assert [PR102989] > > phiopt: Fix phiopt

Re: Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

>> I saw you has update serveral testcase, why update instead of add new >> testcase?? Since original testcase failed after this patch. >> could you say more about why some testcase added __riscv_vadd_vv_i8mf8 >> or add some more dependency of vl variable? These are 2 separate questions. 1. Why

[PATCH] RISC-V: Add riscv-vsetvl.def to t-riscv

This patch will be backport to GCC 13 and commit to trunk. gcc/ChangeLog: * config/riscv/t-riscv: Add riscv-vsetvl.def --- gcc/config/riscv/t-riscv | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/riscv/t-riscv b/gcc/config/riscv/t-riscv index 1252d6f851a.

[PATCH] RISC-V: Clang format riscv-vsetvl.cc[NFC]

Commited. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (change_insn): Clang format. (vector_infos_manager::all_same_ratio_p): Ditto. (vector_infos_manager::all_same_avl_p): Ditto. (pass_vsetvl::refine_vsetvls): Ditto. (pass_vsetvl::cleanup_vsetvls): Ditto.

  1   2   >