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

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

[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

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]

[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: [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: [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

[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: [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] 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, 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: [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] 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, 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. > > > >

[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):

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

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: 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

[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 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

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] 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] 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] 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] 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] _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][PUSHED] Fix cfg maintenance after inlining in AutoFDO

On Tue, May 9, 2023 at 12:27 AM Eugene Rozenfeld via Gcc-patches wrote: > > Todo from early_inliner needs to be propagated so that > cleanup_tree_cfg () is called if necessary. > > This bug was causing an assert in get_loop_body during > ipa-sra in autoprofiledbootstrap build since loops weren't

[PATCH 4/6] aarch64: Relax predicate register matches

Most governing predicate operands require p0-p7, but some instructions also allow p8-p15. Non-gp uses of predicates often also allow all of p0-p15. This patch fixes up cases where we required p0-p7 unnecessarily. In some cases we match the definition (typically a comparison, PFALSE or PTRUE),

[PATCH 2/6] aarch64: Allow moves after tied-register intrinsics

Some ACLE intrinsics map to instructions that tie the output operand to an input operand. If all the operands are allocated to different registers, and if MOVPRFX can't be used, we will need a move either before the instruction or after it. Many tests only matched the "before" case; this patch

[PATCH 3/6] aarch64: Relax ordering requirements in SVE dup tests

Some of the svdup tests expand to a SEL between two constant vectors. This patch allows the constants to be formed in either order. gcc/testsuite/ * gcc.target/aarch64/sve/acle/asm/dup_s16.c: When using SEL to select between two constant vectors, allow the constant moves to appear

[PATCH 0/6] aarch64: Avoid hard-coding specific register allocations

I have a patch that seems to improve register allocation for SIMD lane operations, and for similar instructions that require a reduced register range. However, it showed that a lot of asm tests are sensitive to the current register allocation. This patch series tries to correct the affected

[PATCH 1/6] aarch64: Fix move-after-intrinsic function-body tests

Some of the SVE ACLE asm tests tried to be agnostic about the instruction order, but only one of the alternatives was exercised in practice. This patch fixes latent typos in the other versions. gcc/testsuite/ * gcc.target/aarch64/sve2/acle/asm/aesd_u8.c: Fix expected register

[committed, gcc 12] Fix ICE related to implicit access attributes for VLA arguments [PR105660]

Bootstrapped and regression tested on x86-64. Fix ICE related to implicit access attributes for VLA arguments [PR105660] When constructing the specifier string when merging an access attribute that encodes information about VLA arguments, the string was constructed in

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

Update the memory allocated bytes for both the all 12-bits patch and code 8-bits + mode 16-bits. Bytes allocated with O2: --- Benchmark

[PATCH 6/6] aarch64: Avoid hard-coding specific register allocations

Some tests hard-coded specific allocations for temporary registers, whereas the RA should be free to pick anything that doesn't force unnecessary moves or spills. gcc/testsuite/ * gcc.target/aarch64/asimd-mul-to-shl-sub.c: Allow any register allocation for temporary results,

[PATCH 5/6] aarch64: Relax FP/vector register matches

There were many tests that used [0-9] to match an FP or vector register, but that should allow any of 0-31 instead. asm-x-constraint-1.c required s0-s7, but that's the range for "y" rather than "x". "x" allows s0-s15. sve/pcs/return_9.c required z2-z7 (the initial set of available

[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] 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

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

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

[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

[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 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 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 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 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. *

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: 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

[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 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 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 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 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 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 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 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.

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

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

[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

[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] Detect bswap + rotate for byte permutation in pass_bswap.

The patch doesn't handle: 1. cast64_to_32, 2. memory source with rsize < range. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR middle-end/108938 * gimple-ssa-store-merging.cc (is_bswap_or_nop_p): New function, cut from

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

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 introduced assume attribute says "We could

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

On Tue, 9 May 2023, Li, Pan2 wrote: > Update the memory allocated bytes for both the all 12-bits patch and > code 8-bits + mode 16-bits. Just to throw in a comment here - for IL tree/GIMPLE is the more important part since the whole program will be in tree/GIMPLE while we only have a single

Re: [PATCH v3] Add pattern to convert vector shift + bitwise and + multiply to vector compare in some cases.

On Tue, Dec 20, 2022 at 1:23 PM Manolis Tsamis wrote: > > When using SWAR (SIMD in a register) techniques a comparison operation within > such a register can be made by using a combination of shifts, bitwise and and > multiplication. If code using this scheme is vectorized then there is >

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

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 attribute without arguments like [[noreturn...]]

[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

Re: Let each 'lto_init' determine the default 'LTO_OPTIONS', and 'torture-init' the 'LTO_TORTURE_OPTIONS' (was: Update testsuite to run with slim LTO)

Hi! 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: > > > Hi! > > > > This very likely isn't the only instance of such a kind of problem in the > > GCC testsuite ;-) -- but it's one that I've run into,

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

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

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. >

[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 01/10] arm: [MVE intrinsics] add unary shape

> -Original Message- > From: Christophe Lyon > Sent: Friday, May 5, 2023 5:49 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 01/10] arm: [MVE intrinsics] add unary shape > > This patch adds 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: 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: [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: 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: 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: 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); + ... +

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

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

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

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

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 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

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 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 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:

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

[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

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: [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 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] 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] 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

  1   2   >