RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

Just migrated to the pointer_mux for the var-tracking, it works well even the bitsize of tree_base code is different from the rtl_def code. I will prepare the PATCH if there is no surprise from the X86 bootstrap test. Thanks Richard for pointing out the pointer_mux, ! Pan -Original

[Committed] New testcase

While I was writting a match.pd patch, I can across GCC was being miscompiled but no testcase was failing. So this adds that testcase. Committed after testing on x86_64 with make check-gcc RUNTESTFLAGS="execute.exp=20230509-1.c" gcc/testsuite/ChangeLog: * gcc.c-torture/execut

[PATCH] _Hashtable implementation cleanup

Hi Rather than providing a series of patches for _Hashtable I prefer to submit them one by one. It will maximize the chances to have some of them in gcc 14. I'm starting with this simple patch to do some cleanup in the current implementation to ease compiler optimizations by making some

Re: [PATCH V2] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s instructions satisfying REG_P(operand[1]) in -O0.

LGTM. Let's wait for kito's feedback. Thanks :) juzhe.zh...@rivai.ai From: Li Xu Date: 2023-05-10 12:02 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; Li Xu Subject: [PATCH V2] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s instructions satisfying REG_P(operand[1]) in -O0. This

[PATCH V2] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s instructions satisfying REG_P(operand[1]) in -O0.

This issue happens is because the operand1 of scalar move can be REG_P (operand[1]) in the O0 case, which causes the VSETVL PASS to not insert the vsetvl instruction correctly, and the compiler crashes. Consider this following case: int16_t foo1 (void *base, size_t vl) { int16_t maxVal =

[PATCH] RISC-V: Support const series vector for RVV auto-vectorization

From: Juzhe-Zhong This patch is the prerequiste patch for more RVV auto-vectorization support. Since when we enable a very simple binary operations, we will end up with such following ICE: during RTL pass: expand add_run-1.c: In function 'main': add_run-1.c:28:1: internal compiler error:

Re: [PATCH] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s instructions satisfying REG_P(operand[1]) in -O0.

Thanks for fix this. It seems that we don't have much testing in O0 (Mostly testing in optimize > 0). A couple of comments here: >> if (avl == NULL_RTX && !optimize) Chang it into ---> info.has_avl_no_reg () >> \ No newline at end of file Check each test files make sure each file has a newline

[PATCH] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s instructions satisfying REG_P(operand[1]) in -O0.

This issue happens is because the operand1 of scalar move can be REG_P (operand[1]) in the O0 case, which causes the VSETVL PASS to not insert the vsetvl instruction correctly, and the compiler crashes. Consider this following case: int16_t foo1 (void *base, size_t vl) { int16_t maxVal =

Re: [PATCH V2 2/2] [x86] x86: Add a new option -mdaz-ftz to enable FTZ and DAZ flags in MXCSR.

On Thu, May 4, 2023 at 5:49 PM Richard Biener wrote: > > On Thu, May 4, 2023 at 7:37 AM Hongtao Liu via Gcc-patches > wrote: > > > > On Thu, May 4, 2023 at 1:35 PM Hongtao Liu wrote: > > > > > > On Thu, Dec 22, 2022 at 4:04 PM Uros Bizjak wrote: > > > > > > > > On Thu, Dec 22, 2022 at 5:40 AM

[PATCH] Fixes and workarounds for warnings during autoprofiledbootstrap build

autoprofiledbootstrap build produces new warnings since inlining decisions are different from other builds. This patch contains fixes and workarounds for those warnings. Tested on x86_64-pc-linux-gnu. gcc/ChangeLog: * config/i386/i386-expand.cc (expand_vec_perm_interleave2): Work around

[committed] CRIS: Fix ccmode typo in cris_postdbr_cmpelim

Typo spotted while doing CCmode improvements, as a missed optimization. It's almost visible from the patch context; there's not much done in terms of "mode-adjustment" when replacing (reg:CC CRIS_CC0_REGNUM) with a copy! This bug affects functions in the newlib printf-formatting functions

RE: [EXTERNAL] Re: [PATCH][PUSHED] Fix cfg maintenance after inlining in AutoFDO

>> free_dominance_info (CDI_DOMINATORS); @@ -1674,7 +1677,7 @@ >> auto_profile (void) >> pop_cfun (); >>} >> >> - return TODO_rebuild_cgraph_edges; >> + return 0; >This change isn't mentioned - was it accidential? No, it wasn't accidental. There is no reason to return

Re: [PATCH] libffi: fix handling of homogeneous float128 structs [PR109447]

On 5/9/23 3:50 PM, Andreas Schwab wrote: > On Mai 09 2023, Peter Bergner via Gcc-patches wrote: > >> It's almost as if the top level build machinery >> adds a LD_LIBRARY_PATH=... > > See how the toplevel Makefile sets LD_LIBRARY_PATH (via RPATH_ENVVAR) if > gcc-bootstrap is set. I'm sorry to be

Re: [PATCH] libffi: fix handling of homogeneous float128 structs [PR109447]

On Mai 09 2023, Peter Bergner via Gcc-patches wrote: > It's almost as if the top level build machinery > adds a LD_LIBRARY_PATH=... See how the toplevel Makefile sets LD_LIBRARY_PATH (via RPATH_ENVVAR) if gcc-bootstrap is set. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578

Re: [PATCH] Add RTX codes for BITREVERSE and COPYSIGN.

On Sat, 6 May 2023, Roger Sayle wrote: > An analysis of backend UNSPECs reveals that two of the most common UNSPECs > across target backends are for copysign and bit reversal. This patch > adds RTX codes for these expressions to allow their representation to > be standardized, and them to

Re: [PATCH] c++, v2: Reject attributes without arguments used as pack expansion [PR109756]

On 5/9/23 15:23, Jakub Jelinek wrote: On Tue, May 09, 2023 at 01:17:09PM -0400, Jason Merrill wrote: How about changing cp_parser_std_attribute to set TREE_VALUE to error_mark_node if it skips arguments? In limited testing that seems to work (tried GXX_TESTSUITE_STDS=98,11,14,17,20,2b make

Re: [Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964

Duuh! There's even a choice :-) Paul On Tue, 9 May 2023 at 19:29, Harald Anlauf wrote: > Hi Paul, > > On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > This problem caused the gimplifier failure because the reference chain > > ending in an inquiry_len still

Re: [PATCH] libffi: fix handling of homogeneous float128 structs [PR109447]

On 5/5/23 4:42 PM, Jakub Jelinek wrote: > On Thu, May 04, 2023 at 02:29:34PM -0500, Peter Bergner wrote: >> Merged from upstream libffi commit: 464b4b66e3cf3b5489e730c1466ee1bf825560e0 >> >> 2023-05-03 Dan Horák >> >> libffi/ >> PR libffi/109447 >> * src/powerpc/ffi_linux64.c

Re: Question on patch -fprofile-partial-training

Honza, Thanks a lot for your comments. > On May 9, 2023, at 6:22 AM, Jan Hubicka wrote: > > > From my understanding, -fprofile-partial-training is one important option > for PGO performance. I don't think so, speed benefit would be rather small I guess. >>> I saw some

[committed] libstdc++: Fix pretty printers and add tests

Tested powerpc64le-linux. Pushed to trunk. I'll backport to gcc-13 too. -- >8-- This fixes a couple of errors in the printers for chrono types, and adds tests to ensure they keep working. libstdc++-v3/ChangeLog: * python/libstdcxx/v6/printers.py (StdChronoDurationPrinter):

[PATCH] configure: Implement --enable-host-pie

[ This is my third attempt to add this configure option. The first version was approved but it came too late in the development cycle. The second version was also approved, but I had to revert it: . I've fixed the problem (by

[PATCH] c++, v2: Reject attributes without arguments used as pack expansion [PR109756]

On Tue, May 09, 2023 at 01:17:09PM -0400, Jason Merrill wrote: > How about changing cp_parser_std_attribute to set TREE_VALUE to > error_mark_node if it skips arguments? In limited testing that seems to work (tried GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j32 -k check-g++

Re: Testsuite: Add missing 'torture-init'/'torture-finish' around 'LTO_TORTURE_OPTIONS' usage (was: Let each 'lto_init' determine the default 'LTO_OPTIONS', and 'torture-init' the 'LTO_TORTURE_OPTIONS

Hi Thomas, On Tue, 9 May 2023 at 17:17, Christophe Lyon wrote: > Hi! > > On Tue, 9 May 2023 at 11:00, Thomas Schwinge > wrote: > >> Hi Christophe! >> >> On 2023-05-09T09:32:55+0200, Christophe Lyon >> wrote: >> > On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches < >>

Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE

On Tue, May 09, 2023 at 08:35:00PM +0200, Harald Anlauf wrote: > On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote: > > > > It's not needed. See above. gfc_state_stack->previous is referenced > > a few lines above the if-stmt. The reference will segfault if the > > pointer is NULL. > > > >

Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE

On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote: On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote: Hi Paul, On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote: Hi All, Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because this testcase checked

Re: [PATCH 01/16] arm: [MVE intrinsics] add binary_maxvminv shape

On 5/9/23 15:50, Kyrylo Tkachov wrote: Hi Christophe, -Original Message- From: Christophe Lyon Sent: Tuesday, May 9, 2023 1:19 PM To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; Richard Earnshaw ; Richard Sandiford Cc: Christophe Lyon Subject: [PATCH 01/16] arm: [MVE intrinsics]

Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE

On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote: > Hi Paul, > > On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because > > this testcase checked that finalizable derived types could

Re: [Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964

Hi Paul, On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote: Hi All, This problem caused the gimplifier failure because the reference chain ending in an inquiry_len still retained a full array reference. This had already been corrected for deferred character lengths but the fix extends

[PATCH v2 06/16] arm: add smax/smin expanders for v*hf

This patch adds the missing expanders for smax/smin for v*hf modes, by using the VDQWH iterator instead of VALLW. 2022-09-08 Christophe Lyon gcc/ * config/arm/vec-common.md (smin3): Use VDQWH iterator. (smax3): Likewise. --- gcc/config/arm/vec-common.md | 12

Re: [Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE

Hi Paul, On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote: Hi All, Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because this testcase checked that finalizable derived types could not be specified in a submodule. I have replaced the original test with a test of

[PATCH 1/2] aarch64: Fix cut-&-pasto in aarch64-sve2-acle-asm.exp

aarch64-sve2-acle-asm.exp tried to prevent --with-cpu/tune from affecting the results, but it used sve_flags rather than sve2_flags. This was a silent failure when running the full testsuite, but was a fatal error when running the harness individually. Tested on aarch64-linux-gnu, pushed to

Re: [PATCH] c++: noexcept-spec from nested class confusion [PR109761]

On 5/9/23 12:35, Patrick Palka wrote: When processing a noexcept-spec from a nested class after completion of the outer class (since a noexcept-spec is a complete-class context), we pass to noexcept_override_late_checks the outer class type instead of the nested class type, which leads to bogus

RE: [PATCH 06/16] arm: add smax/smin expanders for v*hf

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, May 9, 2023 6:33 PM > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org; > Richard Earnshaw ; Richard Sandiford > > Subject: Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf > > > > On 5/9/23 19:31, Kyrylo Tkachov

Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf

On 5/9/23 19:31, Kyrylo Tkachov wrote: -Original Message- From: Christophe Lyon Sent: Tuesday, May 9, 2023 6:18 PM To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org; Richard Earnshaw ; Richard Sandiford Subject: Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf On 5/9/23

RE: [PATCH 06/16] arm: add smax/smin expanders for v*hf

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, May 9, 2023 6:18 PM > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org; > Richard Earnshaw ; Richard Sandiford > > Subject: Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf > > > > On 5/9/23 15:48, Kyrylo Tkachov

Re: Support parallel testing in libgomp, part II [PR66005]

Thomas, On Fri, 5 May 2023 10:59:31 +0200 Thomas Schwinge wrote: > Worth noting is that with nvptx offloading, there is one execution test case > that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively > stalls progress for almost 5 min: Short of fixing it for real you

Re: [PATCH] c++: error-recovery ICE with unstable satisfaction [PR109752]

On 5/9/23 12:35, Patrick Palka wrote: After diagnosing and recovering from unstable satisfaction, it's possible to evaluate an atom for the first time noisily rather than quietly. The satisfaction cache tries to handle this situation gracefully, but apparently not gracefully enough: we inserted

Re: [PATCH 06/16] arm: add smax/smin expanders for v*hf

On 5/9/23 15:48, Kyrylo Tkachov wrote: -Original Message- From: Christophe Lyon Sent: Tuesday, May 9, 2023 1:19 PM To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; Richard Earnshaw ; Richard Sandiford Cc: Christophe Lyon Subject: [PATCH 06/16] arm: add smax/smin expanders for v*hf

Re: [PATCH] c++: Reject attributes without arguments used as pack expansion [PR109756]

On 5/9/23 04:12, Jakub Jelinek wrote: Hi! The following testcase shows we silently accept (and ignore) attributes without arguments used as pack expansions. This is because we call make_pack_expansion and that starts with if (!arg || arg == error_mark_node) return arg; Now, an

Re: [PATCH] c++: error-recovery ICE with unstable satisfaction [PR109752]

On Tue, 9 May 2023, Patrick Palka wrote: > After diagnosing and recovering from unstable satisfaction, it's > possible to evaluate an atom for the first time noisily rather than > quietly. The satisfaction cache tries to handle this situation > gracefully, but apparently not gracefully enough:

[PATCH] c++: noexcept-spec from nested class confusion [PR109761]

When processing a noexcept-spec from a nested class after completion of the outer class (since a noexcept-spec is a complete-class context), we pass to noexcept_override_late_checks the outer class type instead of the nested class type, which leads to bogus errors in the below test. This patch

[PATCH] c++: error-recovery ICE with unstable satisfaction [PR109752]

After diagnosing and recovering from unstable satisfaction, it's possible to evaluate an atom for the first time noisily rather than quietly. The satisfaction cache tries to handle this situation gracefully, but apparently not gracefully enough: we inserted an empty slot in the cache, and left it

[PATCH] rtl: AArch64: New RTL for ABD

>From afa416dab831795f7e1114da2fb9e94ea3b8c519 Mon Sep 17 00:00:00 2001 From: oluade01 Date: Fri, 14 Apr 2023 15:10:07 +0100 Subject: [PATCH 2/4] AArch64: New RTL for ABD This patch adds new RTL and tests for sabd and uabd PR tree-optimization/109156 gcc/ChangeLog: *

[PATCH] vect: Missed opportunity to use [SU]ABD

>From 0b5f469171c340ef61a48a31877d495bb77bd35f Mon Sep 17 00:00:00 2001 From: oluade01 Date: Fri, 14 Apr 2023 10:24:43 +0100 Subject: [PATCH 1/4] Missed opportunity to use [SU]ABD This adds a recognition pattern for the non-widening absolute difference (ABD). gcc/ChangeLog: *

Re: [gcc13 backport] RISCV: Inline subword atomic ops

Ping. On 5/3/23 10:19, Patrick O'Neill wrote: RISC-V has no support for subword atomic operations; code currently generates libatomic library calls. This patch changes the default behavior to inline subword atomic calls (using the same logic as the existing library call). Behavior can be

[Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964

Hi All, This problem caused the gimplifier failure because the reference chain ending in an inquiry_len still retained a full array reference. This had already been corrected for deferred character lengths but the fix extends this to all characters without a length expression and integer

[PATCH] vect: Missed opportunity to use [SU]ABD

>From 0b5f469171c340ef61a48a31877d495bb77bd35f Mon Sep 17 00:00:00 2001 From: oluade01 Date: Fri, 14 Apr 2023 10:24:43 +0100 Subject: [PATCH 1/4] Missed opportunity to use [SU]ABD This adds a recognition pattern for the non-widening absolute difference (ABD). gcc/ChangeLog: *

[Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE

Hi All, Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because this testcase checked that finalizable derived types could not be specified in a submodule. I have replaced the original test with a test of the patch. Thanks also to Malcolm Cohen for guidance on this. OK for

Re: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

No, I don't think so. Some testcases the reason I added -fno-vect-cost-model here is because we don't have enough patterns to enable some auto-vectorizations. I add -fno-vect-cost-model to force enable auto-vectorizations for such cases for testing. juzhe.zh...@rivai.ai From: Kito Cheng

Re: Testsuite: Add missing 'torture-init'/'torture-finish' around 'LTO_TORTURE_OPTIONS' usage (was: Let each 'lto_init' determine the default 'LTO_OPTIONS', and 'torture-init' the 'LTO_TORTURE_OPTIONS

Hi! On Tue, 9 May 2023 at 11:00, Thomas Schwinge wrote: > Hi Christophe! > > On 2023-05-09T09:32:55+0200, Christophe Lyon > wrote: > > On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > >> On Wed, 3 May 2023, Thomas Schwinge wrote: > >> > "Let

Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

One more question from me: should we just add -fno-vect-cost-model to AUTOVEC_TEST_OPTS? On Tue, May 9, 2023 at 10:29 PM Kito Cheng wrote: > > Oh, checked default_builtin_support_vector_misalignment and I realized > we can just remove riscv_support_vector_misalignment at all... > > > On Tue,

Re: Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

Yes We can remove it but I still keep it here and add comment for TODO. Since we may want to support it for VLS modes, like ARM SVE, they have Advanced SIMD modes (128bit VLS mode): /* Return true if the vector misalignment factor is supported by the target. */ static bool

Re: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support

More details for Case 2: + _72 = MIN_EXPR ; + _75 = MIN_EXPR ; + ... + .LEN_STORE (vectp_f.8_51, 128B, _75, { 1, 2, 1, 2, 1, 2, 1, 2 }, 0); + vectp_f.8_56 = vectp_f.8_51 + 16; + .LEN_STORE (vectp_f.8_56, 128B, _72, { 1, 2, 1, 2, 1, 2, 1, 2 }, 0); + ... +

Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

Oh, checked default_builtin_support_vector_misalignment and I realized we can just remove riscv_support_vector_misalignment at all... On Tue, May 9, 2023 at 10:18 PM juzhe.zhong wrote: > > riscv_support_vector_misalignment update makes some of the testcase check > fail. I have checked the

Re: [PATCH] c++: Reject pack expansion of assume attribute [PR109756]

On 5/9/23 04:22, Jakub Jelinek wrote: Hi! http://eel.is/c++draft/dcl.attr#grammar-4 says "In an attribute-list, an ellipsis may appear only if that attribute's specification permits it." and doesn't explicitly permit it on any standard attribute. The https://wg21.link/p1774r8 paper which

Re: [PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

I am ok with both changes but I tried to build some test cases, and it seems the changes are caused by options update, not caused by the riscv_support_vector_misalignment update? so I would like to see the testcase should split out into a separated patch. > +/* Return true if the vector

RE: [PATCH 01/16] arm: [MVE intrinsics] add binary_maxvminv shape

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Tuesday, May 9, 2023 1:19 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 01/16] arm: [MVE intrinsics] add binary_maxvminv shape > >

RE: [PATCH 06/16] arm: add smax/smin expanders for v*hf

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, May 9, 2023 1:19 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 06/16] arm: add smax/smin expanders for v*hf > > This patch adds the

Re: [PATCH V5] Use reg mode to move sub blocks for parameters and returns

Hi, Jeff Law writes: > On 5/3/23 23:49, guojiufu wrote: >> Hi, >> >> On 2023-05-01 03:00, Jeff Law wrote: >>> On 3/16/23 21:39, Jiufu Guo wrote: Hi, When assigning a parameter to a variable, or assigning a variable to return value with struct type, and the parameter/return

Re: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support

Thanks, Richard. >> Could you go into more details about this? I imagined that for case 3, >> there would be a single SELECT_VL that decides how many scalar iterations >> will be handled by the current vector iteration, then we would "expand" >> the result (using MIN_EXPRs) to the multi-control

[committed] Eliminate more comparisons on the H8 port

This patch fixes a minor code quality issue I found while testing LRA on the H8. Specifically we have a peephole which converts a comparison of a memory location against zero into a load + comparison which is actually more efficient. This triggers when there are registers available at the

libgomp testsuite: Get rid of 'lang_test_file_found' (was: libgomp C++, Fortran testsuites: Resolve 'lang_test_file_found' first (was: libgomp testsuite: Localize 'lang_[...]' etc. (was: libgomp tests

Hi! On 2023-05-09T14:59:53+0200, I wrote: > On 2023-05-09T14:54:21+0200, I wrote: >> [...] libgomp testsuite is a bit weird [...]: that every '*.exp' file >> begins with a bunch of conditional 'unset lang_[...]' to clean up what >> the previous '*.exp' file left behind. I propose to simplify

libgomp C++, Fortran testsuites: Resolve 'lang_test_file_found' first (was: libgomp testsuite: Localize 'lang_[...]' etc. (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?))

Hi! On 2023-05-09T14:54:21+0200, I wrote: > [...] libgomp testsuite is a bit weird [...]: that every '*.exp' file > begins with a bunch of conditional 'unset lang_[...]' to clean up what > the previous '*.exp' file left behind. I propose to simplify this as per > the attached "libgomp testsuite:

Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support

钟居哲 writes: > Hi, Richards. I would like to give more information about this patch so that > it will make this patch easier for you to review. > > Currently, I saw we have 3 situations that we need to handle in case of loop > control IV in auto-vectorization: > 1. Single rgroup loop control

libgomp testsuite: Localize 'lang_[...]' etc. (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?)

Hi! On 2014-11-04T10:31:37-0800, Mike Stump wrote: > I wonder if any variables that you set that need to be cleared out are, that > seems a defect in the api or conventions we use and it can screw following > tests with a wrong environment in subtle ways. I could miss accidental bleed > over

libgomp testsuite: Use 'lang_test_file_found' instead of 'lang_test_file' (was: libgomp testsuite: Only use 'blddir' if set (was: libgomp C++ testsuite: Don't compute 'blddir' twice (was: libgomp test

Hi! On 2023-05-09T14:39:53+0200, I wrote: > On 2023-05-09T14:36:53+0200, I wrote: >> On 2014-11-04T10:31:37-0800, Mike Stump wrote: >>> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote: On Wed, 15 Oct 2014 17:46:48 +0200, I wrote: > [...] > > Am I on the right track with the

libgomp testsuite: Only use 'blddir' if set (was: libgomp C++ testsuite: Don't compute 'blddir' twice (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?))

Hi! On 2023-05-09T14:36:53+0200, I wrote: > On 2014-11-04T10:31:37-0800, Mike Stump wrote: >> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote: >>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote: [...] Am I on the right track with the following? >>> >>> Nobody commented, which also

libgomp C++ testsuite: Don't compute 'blddir' twice (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?)

Hi! On 2014-11-04T10:31:37-0800, Mike Stump wrote: > On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote: >> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote: >>> [...] >>> >>> Am I on the right track with the following? >> >> Nobody commented, which also means nobody disagreed > > :-) > >> OK to

[PATCH 05/16] arm: [MVE intrinsics] rework vmaxvq vminvq vmaxavq vminavq

Implement vmaxvq, vminvq, vmaxavq, vminavq using the new MVE builtins framework. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (FUNCTION_PRED_P_S_U) (FUNCTION_PRED_P_S): New. (vmaxavq, vminavq, vmaxvq, vminvq): New. *

[PATCH 15/16] arm: [MVE intrinsics] factorize vmaxaq vminaq

Factorize vmaxaq vminaq so that they use the same pattern. 2022-09-08 Christophe Lyon gcc/ * config/arm/iterators.md (MVE_VMAXAVMINAQ, MVE_VMAXAVMINAQ_M): New. (mve_insn): Add vmaxa, vmina. (supf): Add VMAXAQ_S, VMAXAQ_M_S, VMINAQ_S, VMINAQ_M_S.

[PATCH 09/16] arm: [MVE intrinsics] factorize vmaxnmavq vmaxnmvq vminnmavq vminnmvq

Factorize vmaxnmavq vmaxnmvq vminnmavq vminnmvq so that they use the same pattern. 2022-09-08 Christophe Lyon gcc/ * config/arm/iterators.md (MVE_VMAXNMxV_MINNMxVQ) (MVE_VMAXNMxV_MINNMxVQ_P): New. (mve_insn): Add vmaxnmav, vmaxnmv, vminnmav, vminnmv. *

[PATCH 07/16] arm: [MVE intrinsics] factorize vmaxnmq vminnmq

Factorize vmaxnmq and vminnmq so that they use the same pattern. 2022-09-08 Christophe Lyon gcc/ * config/arm/iterators.md (MAX_MIN_F): New. (MVE_FP_M_BINARY): Add VMAXNMQ_M_F, VMINNMQ_M_F. (mve_insn): Add vmaxnm, vminnm. (max_min_f_str): New. *

[PATCH 14/16] arm: [MVE intrinsics] add binary_maxamina shape

This patch adds the binary_maxamina shape description. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (binary_maxamina): New. * config/arm/arm-mve-builtins-shapes.h (binary_maxamina): New. --- gcc/config/arm/arm-mve-builtins-shapes.cc | 40

[PATCH 13/16] arm: [MVE intrinsics] rework vmaxnmaq vminnmaq

Implement vmaxnmaq and vminnmaq using the new MVE builtins framework. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (vmaxnmaq, vminnmaq): New. * config/arm/arm-mve-builtins-base.def (vmaxnmaq, vminnmaq): New. *

[PATCH 02/16] arm: [MVE intrinsics] add binary_maxavminav shape

This patch adds the binary_maxavminav shape description. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (binary_maxavminav): New. * config/arm/arm-mve-builtins-shapes.h (binary_maxavminav): New. --- gcc/config/arm/arm-mve-builtins-shapes.cc |

[PATCH 11/16] arm: [MVE intrinsics] rework vmaxnmavq vmaxnmvq vminnmavq vminnmvq

Implement vmaxnmavq vmaxnmvq vminnmavq vminnmvq using the new MVE builtins framework. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (FUNCTION_PRED_P_F): New. (vmaxnmavq, vmaxnmvq, vminnmavq, vminnmvq): New. *

[PATCH 16/16] arm: [MVE intrinsics] rework vmaxaq vminaq

Implement vmaxaq and vminaq using the new MVE builtins framework. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (vmaxaq, vminaq): New. * config/arm/arm-mve-builtins-base.def (vmaxaq, vminaq): New. * config/arm/arm-mve-builtins-base.h

[PATCH 08/16] arm: [MVE intrinsics] rework vmaxnmq vminnmq

Implement vmaxnmq and vminnmq using the new MVE builtins framework. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (vmaxnmq, vminnmq): New. * config/arm/arm-mve-builtins-base.def (vmaxnmq, vminnmq): New. *

[PATCH 04/16] arm: [MVE intrinsics] factorize vmaxvq vminvq vmaxavq vminavq

Factorize vmaxvq vminvq vmaxavq vminavq so that they use the same pattern. 2022-09-08 Christophe Lyon gcc/ * config/arm/iterators.md (MVE_VMAXVQ_VMINVQ, MVE_VMAXVQ_VMINVQ_P): New. (mve_insn): Add vmaxav, vmaxv, vminav, vminv. (supf): Add VMAXAVQ_S, VMAXAVQ_P_S,

[PATCH 10/16] arm: [MVE intrinsics] add support for mve_q_p_f

We can call code_for_mve_q_p_f only once this function exists, which is the case after we factorized vmaxnmavq, vmaxnmvq, vminnmavq and vminnmvq in a previous patch. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-functions.h

[PATCH 12/16] arm: [MVE intrinsics] factorize vmaxnmaq vminnmaq

Factorize vmaxnmaq and vminnmaq so that they use the same pattern. 2022-09-08 Christophe Lyon gcc/ * config/arm/iterators.md (MVE_VMAXNMA_VMINNMAQ) (MVE_VMAXNMA_VMINNMAQ_M): New. (mve_insn): Add vmaxnma, vminnma. * config/arm/mve.md (mve_vmaxnmaq_f,

[PATCH 06/16] arm: add smax/smin expanders for v*hf

This patch adds the missing expanders for smax/smin for v*hf modes. 2022-09-08 Christophe Lyon gcc/ * config/arm/vec-common.md (smin3): New. (smax3): New. --- gcc/config/arm/vec-common.md | 14 ++ 1 file changed, 14 insertions(+) diff --git

[PATCH 01/16] arm: [MVE intrinsics] add binary_maxvminv shape

This patch adds the binary_maxvminv shape description. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (binary_maxvminv): New. * config/arm/arm-mve-builtins-shapes.h (binary_maxvminv): New. --- gcc/config/arm/arm-mve-builtins-shapes.cc | 30

[PATCH 03/16] arm: [MVE intrinsics add unspec_mve_function_exact_insn_pred_p

Introduce a function that will be used to build intrinsics that use p predication. 2022-09-08 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-functions.h (class unspec_mve_function_exact_insn_pred_p): New. --- gcc/config/arm/arm-mve-builtins-functions.h | 64

[PATCH][RFC] c-family: Implement __has_feature and __has_extension [PR60512]

Hi, This patch implements clang's __has_feature and __has_extension in GCC. Currently the patch aims to implement all documented features (and some undocumented ones) following the documentation at https://clang.llvm.org/docs/LanguageExtensions.html with the following omissions: - C++ type

[PATCH V2] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

From: Juzhe-Zhong This incorrect codes blocks the scalable RVV auto-vectorization. Take a look at this target hook implementation of aarch64. They only have the similiar handling on TARGET_SIMD. They let movmisalign to handle scalable vector of SVE. For RVV, we should follow the same

RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

Sure thing, I will have a try and keep you posted. Pan -Original Message- From: Richard Biener Sent: Tuesday, May 9, 2023 6:26 PM To: Richard Sandiford Cc: Li, Pan2 ; Jeff Law ; Kito Cheng ; juzhe.zh...@rivai.ai; gcc-patches ; palmer ; jakub Subject: Re: [PATCH] machine_mode type

Re: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support

Hi，Richards. Would you mind reviewing this patch? Thanks. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-05-07 23:19 To: juzhe.zhong; gcc-patches CC: richard.sandiford; rguenther Subject: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by variable amount support On 5/4/23

[committed] mux-utils.h: Fix a comment typo

Hi! Trivial comment typo... Committed as obvious to trunk. 2023-05-09 Jakub Jelinek * mux-utils.h: Fix comment typo, avoides -> avoids. --- gcc/mux-utils.h.jj 2023-01-02 09:32:37.423068007 +0100 +++ gcc/mux-utils.h 2023-05-09 12:45:29.235288953 +0200 @@ -34,7 +34,7 @@ // and

Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

On Tue, 9 May 2023, Richard Sandiford wrote: > "Li, Pan2" writes: > > After the bits patch like below. > > > > rtx_def code 16 => 8 bits. > > rtx_def mode 8 => 16 bits. > > tree_base code unchanged. > > > > The structure layout of both the rtx_def and tree_base will be something > > similar as

Re: Question on patch -fprofile-partial-training

> > > > > > > > From my understanding, -fprofile-partial-training is one important > > > > option for PGO performance. > > > > > > I don't think so, speed benefit would be rather small I guess. > > I saw some articles online to introduce this option for gcc10, > >

[committed] testsuite: Add further testcase for already fixed PR [PR109778]

Hi! On Tue, May 09, 2023 at 08:55:56AM +, Richard Biener wrote: > OK. Thanks. I came up with a testcase which reproduces all the way to r10-7469. LTO to avoid early inlining it, so that ccp handles rotates and not shifts before they are turned into rotates. Tested on x86_64-linux

Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

"Li, Pan2" writes: > After the bits patch like below. > > rtx_def code 16 => 8 bits. > rtx_def mode 8 => 16 bits. > tree_base code unchanged. > > The structure layout of both the rtx_def and tree_base will be something > similar as below. As I understand, the lower 8-bits of tree_base will be >

Re: Question on patch -fprofile-partial-training

On 5/4/23 15:37, Qing Zhao wrote: On May 4, 2023, at 9:05 AM, Martin Liška wrote: On 5/4/23 14:54, Qing Zhao wrote: On May 4, 2023, at 4:30 AM, Martin Liška wrote: On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote: Hi, Jan, You added the following patch into gcc10: From

[PATCH] RISC-V: Fix incorrect implementation of TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT

From: Juzhe-Zhong This incorrect codes blocks the scalable RVV auto-vectorization. Take a look at this target hook implementation of aarch64. They only have the similiar handling on TARGET_SIMD. They let movmisalign to handle scalable vector of SVE. For RVV, we should follow the same

Re: [PATCH] tree: Fix up save_expr [PR52339]

> I think we really need Eric (as one who e.g. introduced the > DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that > on the Ada side. DECL_INVARIANT_P is only set on discriminants with no default value and those are really invariant in Ada, i.e. do not change once set. >

Testsuite: Add missing 'torture-init'/'torture-finish' around 'LTO_TORTURE_OPTIONS' usage (was: Let each 'lto_init' determine the default 'LTO_OPTIONS', and 'torture-init' the 'LTO_TORTURE_OPTIONS')

Hi Christophe! On 2023-05-09T09:32:55+0200, Christophe Lyon wrote: > On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches > wrote: >> On Wed, 3 May 2023, Thomas Schwinge wrote: >> > "Let each 'lto_init' determine the default 'LTO_OPTIONS', and >> > 'torture-init' the

[PATCH] i386: Honour -mdirect-extern-access when calling __fentry__

The small and medium PIC code models generate profiling calls that always load the address of __fentry__() via the GOT, even if -mdirect-extern-access is in effect. This deviates from the behavior with respect to other external references, and results in a longer opcode that relies on linker

Re: [PATCH] tree-ssa-ccp, wide-int: Fix up handling of [LR]ROTATE_EXPR in bitwise ccp [PR109778]

On Tue, 9 May 2023, Jakub Jelinek wrote: > Hi! > > The following testcase is miscompiled, because bitwise ccp2 handles > a rotate with a signed type incorrectly. > Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3 > arguments, all other callers just rotate in the right

[PATCH] tree-ssa-ccp, wide-int: Fix up handling of [LR]ROTATE_EXPR in bitwise ccp [PR109778]

Hi! The following testcase is miscompiled, because bitwise ccp2 handles a rotate with a signed type incorrectly. Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3 arguments, all other callers just rotate in the right precision and I think work correctly. ccp works with

  1   2   >