Re: [PATCH v1] Doc: Add Standard-Names ustrunc and sstrunc for integer modes

On Thu, Jul 18, 2024 at 7:35 AM Andrew Pinski wrote: > > On Wed, Jul 17, 2024 at 9:20 PM wrote: > > > > From: Pan Li > > > > This patch would like to add the doc for the Standard-Names > > ustrunc and sstrunc, include both the scalar and vector integer > > modes. > > Thanks for doing this and t

Re: [Ping, Fortran, Patch, PR78466, coarray, v1.1] Fix Explicit cobounds of a procedures parameter not respected

Hi Andre, The code is standard boilerplate in handling arrays and looks OK to me. That said, I know next to nothing about the handling of co-arrays in gfortran. I hope that others can pick up anything that I have missed. Since you are likely to produce a stream (and have already) of co-array patc

Re: [Patch, fortran] PR108889 -[12/13/14/15 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

Hi Andre, > + /* Mark so that rhs "used unallocated" warnings can be issued. > Component > +references do not generate the warnings. */ > + for (ref = expr1->ref; ref; ref = ref->next) > + if (ref->type == REF_COMPONENT) > + break; > Good spot - I had gone blind

Re: [PATCH] Update SLP reductions process.

On Thu, 18 Jul 2024, Jiawei wrote: > This patch improves SLP reduction handling by ensuring proper processing > even for a single reduction statement.Vectorization instances are now built > only when there are multiple scalar statements to combine into an SLP > reduction. > > An example see htt

Re: [PATCH] Improve optimizer to avoid stack spill across pure function call

After further investigation, it appears that that is not the case and the actual problem is the additional cases of .replacement being set makes a long chain of .replacement point to each other, which leads to a long chain of memref_referenced_p calling each other recursively. I don't understan

[PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

From: mayshao Hi Jakub: Thanks for your review,We should just amend this to handle Zhaoxin. Bootstrapped /regtested X86_64. Ok for trunk? BR Mayshao libatomic/ChangeLog: PR target/104688 * config/x86/init.c (__libat_feat1_init): Don't clear bit_AVX on ZHAO

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 03:23:05PM +0800, MayShao-oc wrote: > From: mayshao > > Hi Jakub: > > Thanks for your review,We should just amend this to handle Zhaoxin. > > Bootstrapped /regtested X86_64. > > Ok for trunk? > BR > Mayshao > > libatomic/ChangeLog: > > PR target/1046

Re: [Fortran, Patch, PR82904] Fix [11/12/13/14/15 Regression][Coarray] ICE in make_ssa_name_fn, at tree-ssanames.c:261

Hi Paul, thanks for the review. Applied as gcc-15-2131-g0231b076dc9 . Regards, Andre > > Hi Andre, > > It looks good to me. I am happy to see that the principle of the > patch has Richi's blessing too. > > OK for mainline. I leave it for you (and Richi?) to decide whether to > backport

[committed] testsuite: Fix up builtin-clear-padding-3.c for -funsigned-char

Hi! As reported on gcc-regression, this test FAILs on aarch64, but my r15-2090 change didn't change anything on the generated assembly, just added the forgotten dg-do run directive to the test, so the test has been failing forever, just we didn't know it. I can actually reproduce it on x86_64 wit

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 9:29 AM Jakub Jelinek wrote: > > On Thu, Jul 18, 2024 at 03:23:05PM +0800, MayShao-oc wrote: > > From: mayshao > > > > Hi Jakub: > > > > Thanks for your review,We should just amend this to handle Zhaoxin. > > > > Bootstrapped /regtested X86_64. > > > > Ok for t

RE: [PATCH v1] Doc: Add Standard-Names ustrunc and sstrunc for integer modes

Thanks Richard and Andrew, will commit v2 with that changes. https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657617.html Pan -Original Message- From: Richard Biener Sent: Thursday, July 18, 2024 3:00 PM To: Andrew Pinski Cc: Li, Pan2 ; gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.a

[PATCH v2] LoongArch: Add support to annotate tablejump

This is per the request from the kernel developers. For generating the ORC unwind info, the objtool program needs to analysis the control flow of a .o file. If a jump table is used, objtool has to correlate the jump instruction with the table. On x86 (where objtool was initially developed) it's

Re: [PING^3] [PATCH 00/11] AArch64/OpenMP: Test SVE ACLE types with various OpenMP constructs.

PING^3 on the series please. Thanks, Tejas. On 7/8/24 4:25 PM, Tejas Belagod wrote: Ping^2 on the series please. Thanks, Tejas. On 5/27/24 10:36 AM, Tejas Belagod wrote: Note: This patch series is based on Richard's initial patch    https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606

Re: [PATCH v2] gimple-fold: consistent dump of builtin call simplifications

On Wed, Jul 17, 2024 at 9:07 PM Rubin Gerritsen wrote: > > Sorry for the inconvenience, here the patch is attached as an attachment. Pushed as r15-2134-gcee56fe0ba757c > Rubin > > From: Richard Biener > Sent: 17 July 2024 1:01 PM > To: rubin.gerritsen > Cc: gcc

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 09:34:14AM +0200, Uros Bizjak wrote: > > > + unsigned int ecx2 = 0, family = 0; > > No need to initialize these two variables. The function ignores __get_cpuid result, so at least the FEAT1_REGISTER = 0; is needed before the first __get_cpuid. Do you mean the ecx2 = 0

Re: [PATCH 03/11] AArch64: Diagnose OpenMP offloading when SVE types involved.

On 5/30/24 6:20 PM, Richard Sandiford wrote: Tejas Belagod writes: The target clause in OpenMP is used to offload loop kernels to accelarator peripeherals. target's 'map' clause is used to move data from and to the accelarator. When the data is SVE type, it may not be suitable because of vari

Re: [Patch, fortran] PR108889 -[12/13/14/15 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

Hi Paul, I checked with an coarray and everything seems to work as expected. Good to merge from my side. Thanks for the patch. - Andre On Thu, 18 Jul 2024 08:04:52 +0100 Paul Richard Thomas wrote: > Hi Andre, > > > > + /* Mark so that rhs "used unallocated" warnings can be > > issued. Co

Re: [PATCH] Update SLP reductions process.

Thanks for your quick reply,sorry for the missing of information. I meet this problem in risc-v test: gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-8.c I found that this SLP change will add additional instrutions in the test, please see this link: https://godbolt.org/z/5Tfqs9zqj 在 2024/07/

Re: [Ping, Fortran, Patch, PR78466, coarray, v1.1] Fix Explicit cobounds of a procedures parameter not respected

Hi Paul, thanks for the review. I have experienced that git is a bit picky, when a patch got line breaks from a mailer or something. I usually do `git am ` that also adds the log entry and can `git reset --hard origin/master` easily to get back to the state before the patch application. I will mo

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 9:50 AM Jakub Jelinek wrote: > > On Thu, Jul 18, 2024 at 09:34:14AM +0200, Uros Bizjak wrote: > > > > + unsigned int ecx2 = 0, family = 0; > > > > No need to initialize these two variables. > > The function ignores __get_cpuid result, so at least the > FEAT1_REGISTER =

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 10:12:46AM +0200, Uros Bizjak wrote: > On Thu, Jul 18, 2024 at 9:50 AM Jakub Jelinek wrote: > > > > On Thu, Jul 18, 2024 at 09:34:14AM +0200, Uros Bizjak wrote: > > > > > + unsigned int ecx2 = 0, family = 0; > > > > > > No need to initialize these two variables. > > >

Re: [PATCH] Update SLP reductions process.

On Thu, 18 Jul 2024, Jiawei wrote: > Thanks for your quick reply,sorry for the missing of information. > > I meet this problem in risc-v test: > > gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-8.c > > I found that this SLP change will add additional instrutions in the test, > please see this li

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

Hello Richard: On 18/07/24 1:17 am, Richard Sandiford wrote: > Ajit Agarwal writes: >> Hello All: >> >> This version of patch relaxes store fusion for more use cases. >> >> Common infrastructure using generic code for pair mem fusion of different >> targets. >> >> rs6000 target specific code impl

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 10:21 AM Jakub Jelinek wrote: > > On Thu, Jul 18, 2024 at 10:12:46AM +0200, Uros Bizjak wrote: > > On Thu, Jul 18, 2024 at 9:50 AM Jakub Jelinek wrote: > > > > > > On Thu, Jul 18, 2024 at 09:34:14AM +0200, Uros Bizjak wrote: > > > > > > + unsigned int ecx2 = 0, family

RE: [PATCH] RISC-V: More support of vx and vf for autovec comparison

> > diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md > > index d5793acc999..a772153 100644 > > --- a/gcc/config/riscv/autovec.md > > +++ b/gcc/config/riscv/autovec.md > > @@ -690,7 +690,7 @@ (define_expand "vec_cmp" > > [(set (match_operand: 0 "register_operand") > >

RE: [RFC][middle-end] SLP Early break and control flow support in GCC

On Wed, 17 Jul 2024, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Tuesday, July 16, 2024 4:08 PM > > To: Tamar Christina > > Cc: GCC Patches ; Richard Sandiford > > > > Subject: Re: [RFC][middle-end] SLP Early break and control flow support in > > GC

Re: [PATCHv2, rs6000] Optimize vector construction with two vector doubleword loads [PR103568]

Hi Haochen, on 2024/5/31 11:25, HAO CHEN GUI wrote: > Hi, > This patch optimizes vector construction with two vector doubleword loads. > It generates an optimal insn sequence as "xxlor" has lower latency than > "mtvsrdd" on Power10. > > Compared with previous version, the main change is to us

Re: [PATCH v2] rs6000: Fix .machine cpu selection w/ altivec [PR97367]

Hi Peter, on 2024/7/13 05:48, Peter Bergner wrote: > René's patch seems to have stalled, so here is an updated version of the > patch with the requested changes to his patch. > > I'll note I have added an additional code change, which is to also emit a > ".machine altivec" if Altivec is enabled.

Re: [PATCH ver 3] rs6000, update effective target for tests builtins-10*.c and, vec_perm-runnable-i128.c

Hi Carl, on 2024/7/18 00:15, Carl Love wrote: > GCC maintainers: > > Version 3, in version 2, the ChangeLog didn't get updated to remove the LP64 > references.  Fixed that and updated the patch description per the feedback > from Peter. > > Version 2, removed the lp64 from the target per discu

[PATCH] x86: Don't enable APX_F in 32-bit mode.

I adjusted my patch based on the comments by H.J. And I will add the testcase like gcc.target/i386/pr101395-1.c when the march for APX is determined. Ok for trunk? Thanks, Lingling gcc/ChangeLog: PR target/115978 * config/i386/driver-i386.cc (host_detect_local_cpu): Enable

Re: [PATCH v2 2/8] OpenMP: dispatch + adjust_args tree data structures and front-end interfaces

Paul-Antoine Arras wrote: This patch introduces the OMP_DISPATCH tree node, as well as two new clauses `nocontext` and `novariants`. It defines/exposes interfaces that will be used in subsequent patches that add front-end and middle-end support, but nothing generates these nodes yet. LGTM. OFF

Re: [PATCH v2] gimple ssa: Teach switch conversion to optimize powers of 2 switches

On Wed, 17 Jul 2024, Filip Kastl wrote: > Hi, > > This is the second version of my patch introducing "exponential index > transformation" to the switch conversion pass. See the version 1 mail here: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653120.html > > > Changes made > ---

Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

Let the user turn off ifunc support at configure time if they want to. Currently, the logic in gcc/autoconf.ac will override the default logic in gcc/config.gcc. gcc/ChangeLog: * config.gcc: Default-enable ifunc support for RISC-V on Linux. * autoconf.ac: Honor the default_gnu_indirect_fu

[PATCH][contrib]: support json output from check_GNU_style_lib.py

Hi All, It would be useful to automated tools if check_GNU_style[_lib] supported returning the result in a structured format like json. With this change calling: > cat patch | ./contrib/check_GNU_style.py --format json - | jq . produces: [ { "type": 1, "msg": "lines should not excee

Re: Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

On Jul 18 2024, Maxim Blinov wrote: > +if test $default_gnu_indirect_function = yes; then > + case "${target}" in > +riscv*-*-linux*) > + AC_MSG_CHECKING(linker ifunc IRELATIVE support) > + cat > conftest.s < + .text > + .typefoo_resolver, @function > + foo_resolver:

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

Ajit Agarwal writes: > [...] >>> +// Set subreg for OO mode pair to generate sequential registers given >>> +// insn_info pairs I1, I2 and LOAD_P is true iff load insn and false >>> +// if store insn. >>> +void >>> +rs6000_pair_fusion::set_multiword_subreg (insn_info *i1, insn_info *i2, >>> +

[PATCH] Make 'target-supports.exp' additions for nvptx target generally available

Hi! OK to push (once testing completes) the attached "Make 'target-supports.exp' additions for nvptx target generally available"? The idea of this new scheme is that explicit feature/target-specific stuff isn't kept in 'gcc/testsuite/lib/target-supports.exp', but instead in feature/target-specifi

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

Hello Richard: On 18/07/24 2:04 pm, Ajit Agarwal wrote: > Hello Richard: > > On 18/07/24 1:17 am, Richard Sandiford wrote: >> Ajit Agarwal writes: >>> Hello All: >>> >>> This version of patch relaxes store fusion for more use cases. >>> >>> Common infrastructure using generic code for pair mem f

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote: > > > On 7/9/24 8:35 PM, Xi Ruoyao wrote: > > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote: > > > So I would use tmp (or another word_mode pseudo register) for the > > > destination of that emit_insn.   Then something like: > > > > > >

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 10:31 AM Uros Bizjak wrote: > > On Thu, Jul 18, 2024 at 10:21 AM Jakub Jelinek wrote: > > > > On Thu, Jul 18, 2024 at 10:12:46AM +0200, Uros Bizjak wrote: > > > On Thu, Jul 18, 2024 at 9:50 AM Jakub Jelinek wrote: > > > > > > > > On Thu, Jul 18, 2024 at 09:34:14AM +0200,

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 01:57:11PM +0200, Uros Bizjak wrote: > Attached patch illustrates the proposed improvement with nested cpuid > calls. Bootstrapped and teased with libatomic testsuite. > > Jakub, WDYT? I'd probably keep the FEAT1_REGISTER = 0; before the if (__get_cpuid (1, ...) to avoid t

Re: [REPOST 0/3] Add support for -mcpu=power11

Hi! On Wed, Jul 10, 2024 at 01:32:02PM -0400, Michael Meissner wrote: > Note, this is a repost of the 3 patches I posted on June 4th. The first two > patches are the same. The third patch modifies the power11 tests to do a > compile instead of assemble, and I removed the power11 specific target

Re: [PATCH v2] [libatomic]: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

On Thu, Jul 18, 2024 at 2:07 PM Jakub Jelinek wrote: > > On Thu, Jul 18, 2024 at 01:57:11PM +0200, Uros Bizjak wrote: > > Attached patch illustrates the proposed improvement with nested cpuid > > calls. Bootstrapped and teased with libatomic testsuite. > > > > Jakub, WDYT? > > I'd probably keep th

[PATCH v1] Match: Only allow single use of MIN_EXPR for SAT_TRUNC form 2 [PR115863]

From: Pan Li The SAT_TRUNC form 2 has below pattern matching. From: _18 = MIN_EXPR ; iftmp.0_11 = (unsigned int) _18; To: _18 = MIN_EXPR ; iftmp.0_11 = .SAT_TRUNC (_18); But if there is another use of _18 like below, the transform to the .SAT_TRUNC may have no earnings. For example:

RE: [PATCH v1] Match: Only allow single use of MIN_EXPR for SAT_TRUNC form 2 [PR115863]

> -Original Message- > From: pan2...@intel.com > Sent: Thursday, July 18, 2024 1:27 PM > To: gcc-patches@gcc.gnu.org > Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com; > Tamar Christina ; jeffreya...@gmail.com; > rdapp@gmail.com; hongtao@intel.com; Pan Li

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Thu, 2024-07-18 at 19:54 +0800, Xi Ruoyao wrote: > On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote: > > > > > > On 7/9/24 8:35 PM, Xi Ruoyao wrote: > > > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote: > > > > So I would use tmp (or another word_mode pseudo register) for the > > > > desti

[PATCH] c++: Add [dcl.init.aggr] examples to testsuite

Hi! When working on the #embed optimization support, I went recently through all of reshape_init_r* and today I read in detail all the P3106R1 changes and I believe we implement it that way for years. To double check that, I've added tests with the current [dcl.init.aggr] examples but tested in al

[PATCH] middle-end/115641 - invalid address construction

fold_truth_andor_1 via make_bit_field_ref builds an address of a CALL_EXPR which isn't valid GENERIC and later causes an ICE. The following simply avoids the folding for f ().a != 1 || f ().b != 2 as it is a premature optimization anyway. The alternative would have been to build a TARGET_EXPR arou

[PATCH v2] RISC-V: Implement __init_riscv_features_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

This provides a common abstraction layer to probe the available extensions at run-time. These functions can be used to implement function multi-versioning or to detect available extensions. The advantages of providing this abstraction layer are: - Easy to port to other new platforms. - Easier to m

Re: [PATCH] rs6000: Relax some FLOAT128 expander condition for FLOAT128_IEEE_P [PR105359]

On 7/18/24 12:19 AM, Kewen.Lin wrote: > I guess you meant "Remove" is expected to remove some code explicitly and > can be misleading here, if so how about "Don't check TARGET_LONG_DOUBLE_128 > for FLOAT128_IEEE_P modes"? Yeah, I think that is more clear. Thanks! Peter

Re: [REPOST 1/3] Add support for -mcpu=power11

Hi! [ I reviewed this together with Ke Wen. All blame should go to me, all praise to him. ] On Wed, Jul 10, 2024 at 01:34:26PM -0400, Michael Meissner wrote: > [This is a repost of the June 4th patch] It is not a repost. It is v2. It has important changes. > * config.gcc (rs6000*-*-*

Re: [PATCH] Do not use caller-saved registers for COMDAT functions

On 7/15/24 12:45, Jonathan Yong wrote: On 7/15/24 09:04, LIU Hao wrote: diff --git a/gcc/varasm.cc b/gcc/varasm.cc index 747f74ba1c0..b67a0b524db 100644 --- a/gcc/varasm.cc +++ b/gcc/varasm.cc @@ -7805,6 +7805,8 @@ decl_binds_to_current_def_p (const_tree decl)   for all other declaration ty

[PATCH][RFC] c/106800 - support vector condition operation in C

The following adds support for vector conditionals in C. The support was nearly there already but c_objc_common_truthvalue_conversion rejecting vector types. Instead of letting them pass there unchanged I chose to instead skip it when parsing conditionals instead as a variant with less possible f

[Fortran, Patch, PR77518, (coarray), v1] Fix ICE in sizeof(coarray)

Hi all, the attached patch fixes an ICE when the object supplied to sizeof() is a coarray of class type. This is fixed by taking the class object from the se's class_container. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: v

Re: [REPOST 2/3] Add tuning support for power11

Hi! On Wed, Jul 10, 2024 at 01:35:47PM -0400, Michael Meissner wrote: > * config/rs6000/power10.md (all reservations): Add power11 as an > alternative to power10. That is not a great description of what is actually going on. Just "Add power11." would be better :-) Or "Add power11 be

Re: [PATCH 3/3] Add power11 tests

Hi! On Wed, Jul 10, 2024 at 01:39:05PM -0400, Michael Meissner wrote: > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/power11-1.c > @@ -0,0 +1,12 @@ > +/* { dg-do compile { target powerpc*-*-* } } */ Everything in gcc.target/powerpc is only run for target powerpc*-*-* anyway, so make thi

Re: [PATCH] MATCH: Add simplification for MAX and MIN to match.pd [PR109878]

On Wed, Jul 17, 2024 at 1:29 PM Eikansh Gupta wrote: > > Min and max could be optimized if both operands are defined by > (same) variable restricted by an and(&). For signed types, > optimization can be done when both constant have same sign bit. > The patch also adds optimization for specific cas

Re: [PATCH v1] Match: Only allow single use of MIN_EXPR for SAT_TRUNC form 2 [PR115863]

On Thu, Jul 18, 2024 at 2:27 PM wrote: > > From: Pan Li > > The SAT_TRUNC form 2 has below pattern matching. > From: > _18 = MIN_EXPR ; > iftmp.0_11 = (unsigned int) _18; > > To: > _18 = MIN_EXPR ; > iftmp.0_11 = .SAT_TRUNC (_18); .SAT_TRUNC (left_8); > But if there is another use of _1

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Thu, 2024-07-18 at 20:41 +0800, Xi Ruoyao wrote: > On Thu, 2024-07-18 at 19:54 +0800, Xi Ruoyao wrote: > > On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote: > > > > > > > > > On 7/9/24 8:35 PM, Xi Ruoyao wrote: > > > > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote: > > > > > So I would us

[r15-2135 Regression] FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 31) on Linux/x86_64

On Linux/x86_64, c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc is the first bad commit commit c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc Author: Paul Thomas Date: Thu Jul 18 08:51:35 2024 +0100 Fortran: Suppress bogus used uninitialized warnings [PR108889]. caused FAIL: libgomp.oacc-fortran/pri

Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

David: Ping. Le 2024-06-12 à 08 h 21, Antoni Boucher a écrit : David: Ping. Le 2024-04-26 à 09 h 51, Antoni Boucher a écrit : Now that we have a more general way to check if target-dependent types are supported (see this commit: https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467e

Re: [PATCH] libgccjit: Fix get_size of size_t

David: Ping Le 2024-06-27 à 20 h 49, Antoni Boucher a écrit : Le 2024-06-26 à 18 h 01, David Malcolm a écrit : On Wed, 2024-02-21 at 14:16 -0500, Antoni Boucher wrote: On Thu, 2023-12-07 at 19:57 -0500, David Malcolm wrote: On Thu, 2023-12-07 at 17:26 -0500, Antoni Boucher wrote: Hi. This

Re: [PATCH v2] rs6000: Fix .machine cpu selection w/ altivec [PR97367]

On 7/18/24 4:14 AM, Kewen.Lin wrote: >> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */ >> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */ > > Nit: Both \m looks useless and can be removed. Fine with me. Is that because the \. acts like a \m? >> Ok for trunk and t

Re: [PATCH][RFC] c/106800 - support vector condition operation in C

On Thu, 18 Jul 2024, Richard Biener wrote: > The following adds support for vector conditionals in C. The support > was nearly there already but c_objc_common_truthvalue_conversion > rejecting vector types. Instead of letting them pass there unchanged > I chose to instead skip it when parsing

Re: [PATCH v2] gimple ssa: Teach switch conversion to optimize powers of 2 switches

On Thu 2024-07-18 12:07:42, Richard Biener wrote: > On Wed, 17 Jul 2024, Filip Kastl wrote: > > > > + } > > > > + > > > > + vec v; > > > > + v.create (1); > > > > + v.quick_push (m_final_bb); > > > > + iterate_fix_dominators (CDI_DOMINATORS, v, true); > > > > > > The fina

RE: [PATCH] RISC-V: More support of vx and vf for autovec comparison

> -Original Message- > From: Robin Dapp > Sent: 2024年7月17日 22:43 > To: Demin Han ; gcc-patches@gcc.gnu.org > Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; pan2...@intel.com; > jeffreya...@gmail.com > Subject: Re: [PATCH] RISC-V: More support of vx and vf for autovec > comparison > > H

Re: [PATCH 3/3] Add power11 tests

On 7/18/24 8:23 AM, Segher Boessenkool wrote: > Everything in gcc.target/powerpc is only run for target powerpc*-*-* > anyway, so make this just > > /* { dg-do compile } */ > > please. (Or nothing, it is the default after all, but you may want to > have it explicit). Personally, I do like seein

Re: [PATCH v2 3/8] OpenMP: middle-end support for dispatch + adjust_args

Hi PA, not yet a full review, but some observations: First: Please include the change gcc/fortran/types.def (BT_FN_PTR_CONST_PTR_INT) of "[PATCH v2 7/8] OpenMP: Fortran front-end support for dispatch + adjust_args" Do so either in this patch (3/8) - or in the previous (2/8) one that adds i

Re: [PATCH][RFC] c/106800 - support vector condition operation in C

> Am 18.07.2024 um 16:22 schrieb Alexander Monakov : > >  >> On Thu, 18 Jul 2024, Richard Biener wrote: >> >> The following adds support for vector conditionals in C. The support >> was nearly there already but c_objc_common_truthvalue_conversion >> rejecting vector types. Instead of lettin

[PATCH v3] c++: Hash placeholder constraint in ctp_hasher

This patch addresses a difference between the hash function and the equality function for canonical types of template parameters (ctp_hasher). The equality function uses comptypes (typeck.cc) (with COMPARE_STRUCTURAL) and checks constraint equality for two auto nodes (typeck.cc:1586), while the has

[committed] libatomic: Improve cpuid usage in __libat_feat1_init

Check the result of __get_cpuid and process FEAT1_REGISTER only when __get_cpuid returns success. Use __cpuid instead of nested __get_cpuid. libatomic/ChangeLog: * config/x86/init.c (__libat_feat1_init): Check the result of __get_cpuid and process FEAT1_REGISTER only when __get_cpuid

Re: [PATCH][RFC] c/106800 - support vector condition operation in C

On Thu, 18 Jul 2024, Richard Biener wrote: > >If both b and c are scalars and the type of true?b:c has the same size > >as the element type of a, then b and c are converted to a vector type > >whose elements have this type and with the same number of elements as a. > > > > (in https:

[PATCH v6] c++: Fix constrained auto deduction in templ spec scopes [PR114915]

When deducing auto for `adc_return_type`, `adc_variable_type`, and `adc_decomp_type` contexts (at the usage time), we try to resolve the outermost template arguments to be used for satisfaction. This is done by one of the following, depending on the scope: 1. Checking the `DECL_TEMPLATE_INFO` of t

Re: [RFC] c++: Eagerly substitute auto constraint args in tsubst [PR115030]

On Wed, 2024-07-17 at 15:48 -0400, Patrick Palka wrote: > > I guess you mean B here? > Yes. Apologies for my mistake. > Ah, that's because the substitution failure in the first example > occurs > during constraint _normalization_, and in second example it occurs > during atomic constraint _sat

Re: [r15-2135 Regression] FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 31) on Linux/x86_64

Hi Haochen, Try removing lines 37-41 since these are precisely the bogus warnings that the patch is meant to eliminate. Regards Paul On Thu, 18 Jul 2024 at 14:38, haochen.jiang wrote: > On Linux/x86_64, > > c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc is the first bad commit > commit c3aa339ea50f

Re: [PATCH] MATCH: Add simplification for MAX and MIN to match.pd [PR109878]

On Thu, Jul 18, 2024 at 6:25 AM Richard Biener wrote: > > On Wed, Jul 17, 2024 at 1:29 PM Eikansh Gupta > wrote: > > > > Min and max could be optimized if both operands are defined by > > (same) variable restricted by an and(&). For signed types, > > optimization can be done when both constant h

[PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look OK for trunk/14? -- >8 -- As a followup of r15-2047-g7954bb4fcb6fa8, we also need to consider dependent attributes when recursing into a non-template alias that names a dependent alias template specialization (and so STF_STRIP_DEPEN

Re: [PATCH][RFC] c/106800 - support vector condition operation in C

> Am 18.07.2024 um 17:37 schrieb Alexander Monakov : > >  > On Thu, 18 Jul 2024, Richard Biener wrote: > >>> If both b and c are scalars and the type of true?b:c has the same size >>> as the element type of a, then b and c are converted to a vector type >>> whose elements have this type

Re: [Fortran, Patch, PR77518, (coarray), v1] Fix ICE in sizeof(coarray)

Hi Andre, While I realise that this is not your doing, should we not check DECL_LANG_SPECIFIC ()) before touching GFC_DECL_SAVED_DESCRIPTOR? Or is access guaranteed by the REF_COMPONENT check? A micro-nit line 12 s/User/Use/ Apart from this, it looks to be eminently obvious. OK for mainline. Pa

Re: [PATCH v2] rs6000: Fix .machine cpu selection w/ altivec [PR97367]

On 7/18/24 9:14 AM, Peter Bergner wrote: > On 7/18/24 4:14 AM, Kewen.Lin wrote: >>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */ >>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */ >> >> Nit: Both \m looks useless and can be removed. > > Fine with me. Is that becau

Re: [PATCH] bpf: create modifier for mem operand for xchg and cmpxchg

On 7/15/24 08:33, Cupertino Miranda wrote: > Both xchg and cmpxchg instructions, in the pseudo-C dialect, do not > expect their memory address operand to be surrounded by parentheses. > For example, it should be output as "w0 =cmpxchg32_32(r8+8,w0,w2)" > instead of "w0 =cmpxchg32_32((r8+8),w0,w2)".

Re: [PATCH][RFC] c/106800 - support vector condition operation in C

On Thu, 18 Jul 2024, Richard Biener wrote: > > (also, in C op2 and op3 of a ternary operator always have integer promotions > > applied, but for vector selection we should use unpromoted types) > > Yes. So a good testcase would use char typed variable then. It’s > unfortunate C and C++ do no

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

On Wed, Jul 17, 2024 at 09:30:00PM -0700, Andi Kleen wrote: > Implement a C23 clang compatible musttail attribute similar to the earlier > C++ implementation in the C parser. > > gcc/c/ChangeLog: > > PR c/83324 > * c-parser.cc (struct attr_state): Define with musttail_p. > (c_pa

Re: Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

On 7/18/24 4:09 AM, Maxim Blinov wrote: Let the user turn off ifunc support at configure time if they want to. Currently, the logic in gcc/autoconf.ac will override the default logic in gcc/config.gcc. gcc/ChangeLog: * config.gcc: Default-enable ifunc support for RISC-V on Linux. *

Re: Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

On 7/18/24 12:25 PM, Jeff Law wrote: On 7/18/24 4:09 AM, Maxim Blinov wrote: Let the user turn off ifunc support at configure time if they want to. Currently, the logic in gcc/autoconf.ac will override the default logic in gcc/config.gcc. gcc/ChangeLog: * config.gcc: Default-enable i

Re: [PING][patch, avr] Implement PR90616: Improve adding symbols that are 256-byte aligned

On 7/17/24 12:27 PM, Georg-Johann Lay wrote: y. May be that's already the case with -mlink-relax?  IIRC that was introduced to keep the assembler from resolving label differences when the linker may relax and hence change label differences, because it shredded debug info. You never know if a

Re: [PATCH v3 1/4] c: runtime checking for assigment of VM types

Hi, Martin, I briefly reviewed these 4 patches this week. Overall, I think that this is a nice new security feature to be added into gcc. At the same time, I have the following questions about the patches: 1. Does the name of the option mismatch the description of the option? -fvla-bounds Em

Re: [PATCH] c++: implement DR1363 and DR1496 for __is_trivial [PR85723]

Ping. On Wed, Jun 19, 2024 at 09:54:23AM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > is_trivial was introduced in > > which split POD into is_trivial and is_standard

Re: [PATCH 2/4] c++/modules: Track module purview for deferred instantiations [PR114630]

On 7/18/24 12:33 AM, Nathaniel Shead wrote: On Wed, Jul 17, 2024 at 11:36:26PM -0400, Jason Merrill wrote: On 7/17/24 11:04 PM, Nathaniel Shead wrote: On Wed, Jul 17, 2024 at 01:12:34PM -0400, Jason Merrill wrote: On 5/1/24 11:27 AM, Jason Merrill wrote: On 5/1/24 07:11, Patrick Palka wrote:

libbacktrace patch committed: Use __has_attribute for fallthrough

This libbacktrace patch uses __has_attribute for fallthrough. It also fixes some FALLTHROUGH comments to use ATTRIBUTE_FALLTHROUGH. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian * internal.h: Use __has_attribute to check for fallthrough attribute. * elf.c

Re: [PATCH] c++: implement DR1363 and DR1496 for __is_trivial [PR85723]

On 6/19/24 9:54 AM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- is_trivial was introduced in which split POD into is_trivial and is_standard_layout. Later came CWG 1363. Since

[PATCH] Fortran: character array constructor with >= 4 constant elements [PR103115]

Dear all, here's a quite obvious fix for an ICE when processing an array constructor where the first element is of deferred length, and at least four constant elements followed, or an iterator with at least four elements. There is a code path that then tries to combine these constant elements and

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On 7/18/24 12:45 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look OK for trunk/14? -- >8 -- As a followup of r15-2047-g7954bb4fcb6fa8, we also need to consider dependent attributes when recursing into a non-template alias that names a dependent alias tem

Re: [PATCH v3 1/4] c: runtime checking for assigment of VM types

Am Donnerstag, dem 18.07.2024 um 18:32 + schrieb Qing Zhao: > Hi, Martin, > > I briefly reviewed these 4 patches this week. > > Overall, I think that this is a nice new security feature to be added into > gcc. Thank you! (not only for security! it currently helps me with my numerics) >

[committed] libatomic: Handle AVX+CX16 ZHAOXIN like intel for 16b atomic [PR104688]

From: mayshao PR target/104688 libatomic/ChangeLog: * config/x86/init.c (__libat_feat1_init): Don't clear bit_AVX on ZHAOXIN CPUs. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. Uros. diff --git a/libatomic/config/x86/init.c b/libatomic/config/x86/init.c index 261

[patch,avr] Support new built-in for faster mask computation

This new builtin provides a faster way to compute expressions like 1 << x or ~(1 << x) that are sometimes used as masks for setting bits in the I/O region, and when x is not known at compile-time. The open coded C expression takes 5 + 4 * x cycles to compute an 8-bit result, whereas the builtin

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

On Thu, Jul 18, 2024 at 02:19:21PM -0400, Marek Polacek wrote: > On Wed, Jul 17, 2024 at 09:30:00PM -0700, Andi Kleen wrote: > > Implement a C23 clang compatible musttail attribute similar to the earlier > > C++ implementation in the C parser. > > > > gcc/c/ChangeLog: > > > > PR c/83324 > >

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

On Thu, Jul 18, 2024 at 03:11:56PM -0700, Andi Kleen wrote: > On Thu, Jul 18, 2024 at 02:19:21PM -0400, Marek Polacek wrote: > > On Wed, Jul 17, 2024 at 09:30:00PM -0700, Andi Kleen wrote: > > > Implement a C23 clang compatible musttail attribute similar to the earlier > > > C++ implementation in t

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

> > > > + set_musttail_on_return (retval, xloc, musttail_p); > > > > + > > > >if (retval) > > > > { > > > >tree semantic_type = NULL_TREE; > > > > > > Is it deliberate that set_musttail_on_return is called outside the > > > if (retval) block? If it can be moved into it, set_must

[PATCH, Obvious] rs6000: Catch unsupported ABI errors when using -mrop-protect [PR114759,PR115988]

I'm not sure how my testing of the pr114759-3.c test case didn't see the excess errors on BE, as I did test there. Anyway, the following obvious patches fixes the problem Bill saw. Tested on LE and 32-bit and 64-bit BE. I'll push this tomorrow if there are no objections. Peter rs6000: Catch

  1   2   >