[Bug ipa/109445] r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |ipa CC|

[Bug libstdc++/109445] New: r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445 Bug ID: 109445 Summary: r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%

[PATCH] PR target/109402: v850 (not v850e) variant of __muldi3() moves sp in reversed direction [PR109402]

Where I talk about is: /libgcc/config/v850/lib1funcs.S L2214, L2259 - in a commit 8b1204d7. There are stack-pointer operations. I think these operations: shrink before, grow after --- may reversed way. There is one more consideration; this version of __muldi3() does not use local storage in

Re: [PATCH] [testsuite] [ppc] expect vectorization in gen-vect-11c.c

On Apr 6, 2023, "Kewen.Lin" wrote: > on 2023/4/6 13:20, Alexandre Oliva wrote: >> I confirm I observe the problem with gcc-12 targeting ppc64-vx7r2, >> containing the backported patch, and that the loop is vectorized, >> failing the test. I take that back. My notes indicate I looked into this

Re: [PATCH] [testsuite] [ppc] skip ppc-fortran if fortran is disabled

Hello, Kewen, On Apr 6, 2023, "Kewen.Lin" wrote: > on 2023/4/6 14:19, Alexandre Oliva wrote: >> Skip ppc-fortran.exp if a trivial fortran program cannot be compiled. > IIUC, without this patch and under the configuration disabling fortran, > all the cases in this sub-testsuite would fail?

[PATCH V2] RISC-V: Modified validation information for contracts-tmpl-spec2.C

From: yulong This patch fixes the problem of the contracts-tmpl-spec2.c running failure. When run the dejagnu test, I find that the output is inconsistent with that verified in the testcase. So I try to modify it, and then it can be passed. gcc/testsuite/ChangeLog: *

[PATCH V4] RISC-V: Fix a redefinition bug for the fd-4.c

From: yulong This patch fix a redefinition bug. There are have a definition about mode_t in the fd-4.c, but it duplicates the definition in types.h that be included by stdio.h. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/fd-4.c: delete the definition of mode_t. ---

RE: [PATCH] VECT: Add WHILE_LEN pattern for decrement IV support for auto-vectorization

The bootstrap in X86 passed with this patch applied, target commit id a8c8351cf4fedb842988eed4f73304019c361e86 (13.0.1 20230407). Pan -Original Message- From: Gcc-patches On Behalf Of juzhe.zh...@rivai.ai Sent: Friday, April 7, 2023 9:48 AM To: gcc-patches@gcc.gnu.org Cc:

[RFC] arm: atomics: ARMv7 doubleword atomicity

Dear maintainers of GCC arm port, Can you share your thoughts on the email I've sent to the mailing list? I've originally sent it to Will Deacon, gcc and linux mailing lists, but no one is responding, so I'm pinging you directly. https://gcc.gnu.org/pipermail/gcc/2023-April/241093.html ---

Re: [PATCH] [PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

On Apr 6, 2023, "Kewen.Lin" wrote: > The reason why personally I preferred to fix it with xfail is that: Got it. I'm convinced, and I agree. I tried an xfail in the initial dg-do, but that is no good for a compile error, so I went for a dg-bogus xfail. I hope that will still have the

[PATCH] VECT: Add WHILE_LEN pattern for decrement IV support for auto-vectorization

From: Juzhe-Zhong This patch is to add WHILE_LEN pattern. It's inspired by RVV ISA simple "vvaddint32.s" example: https://github.com/riscv/riscv-v-spec/blob/master/example/vvaddint32.s More details are in "vect_set_loop_controls_by_while_len" implementation and comments. Consider such

Re: Re: [PATCH 2/3] RISC-V: Enable basic RVV auto-vectorization and support WHILE_LEN/LEN_LOAD/LEN_STORE pattern

Address all comments, and fix all of them in these splitted patches: These 5 patches only including RISC-V port changes: https://patchwork.sourceware.org/project/gcc/patch/20230407011143.46004-1-juzhe.zh...@rivai.ai/

[PATCH] RISC-V: Add testcases for RVV auto-vectorization

From: Juzhe-Zhong gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/rvv.exp: Add auto-vectorization testing. * gcc.target/riscv/rvv/vsetvl/vsetvl-17.c: Adapt testcase. * gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-1.c: New test. *

[PATCH] RISC-V: Add local user vsetvl instruction elimination

From: Juzhe-Zhong This patch is to enhance optimization for auto-vectorization. Before this patch: Loop: vsetvl a5,a2... vsetvl zero,a5... vle After this patch: Loop: vsetvl a5,a2 vle gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (local_eliminate_vsetvl_insn): New function.

[PATCH] RISC-V: Enable basic RVV auto-vectorization support

From: Juzhe-Zhong Enable basic auto-vectorization support of WHILE_LEN/LEN_LOAD/LEN_STORE. gcc/ChangeLog: * config/riscv/riscv-protos.h (preferred_simd_mode): New function. (expand_while_len): Ditto. * config/riscv/riscv-v.cc (autovec_use_vlmax_p): Ditto.

[PATCH] RISC-V: Add RVV auto-vectorization compile option

From: Juzhe-Zhong The next patch to enable basic RVV auto-vectorization of VLA auto-vectorization (RVV_SCALABLE) and fixed-length VLS auto-vectorization (RVV_FIXED_VLMAX). We will support RVV_FIXED_VLMIN in the future. gcc/ChangeLog: * config/riscv/riscv-opts.h (enum

[PATCH] RISC-V: Fix incorrect condition of EEW = 64 mode

From: Juzhe-Zhong This patch should be merged before this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614935.html According to RVV ISA, the EEW = 64 is enable only when -march=*zve64* Current condition is incorrect, since -march=*zve32*_zvl64b will enable EEW = 64 which is

Re: [PATCHv4] [AARCH64] Fix PR target/103100 -mstrict-align and memset on not aligned buffers

On Tue, Apr 4, 2023 at 10:48 AM Richard Sandiford via Gcc-patches wrote: > > Andrew Pinski via Gcc-patches writes: > > The problem here is that aarch64_expand_setmem does not change the alignment > > for strict alignment case. > > This is version 4 of the fix, major changes from the last version

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

On Apr 6, 2023, Thomas Schwinge wrote: > Eh, given your "Ooh, nice, I didn't know [...]" comment in > : Oh my, you're right, I apologize, I misremembered. When I wrote "before I saw your patch" yesterday, I meant the formal,

[Bug sanitizer/109444] Possible array overflow without diagnosis in memcpy if called within a virtual method scenario

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444 --- Comment #1 from Andrew Pinski --- There is padding bytes for Foo because the alignment of Foo needs to be the same alignment as a pointer.

[Bug sanitizer/109444] New: Possible array overflow without diagnosis in memcpy if called within a virtual method scenario

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444 Bug ID: 109444 Summary: Possible array overflow without diagnosis in memcpy if called within a virtual method scenario Product: gcc Version: 12.0 Status: UNCONFIRMED

gcc-10-20230406 is now available

Snapshot gcc-10-20230406 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20230406/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

[Bug c++/109356] Enhancement idea to provide clearer missing brace line number

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #5 from Jonny Grant --- I see it is more complicated than I imagined. Thank you for looking into it.

Re: -Wanalyzer-use-of-uninitialized-value always shadows -Wanalyzer-out-of-bounds

On Thu, 2023-04-06 at 13:02 +0200, Benjamin Priour wrote: > Hi David, > I haven't yet looked into your suggestions, probably won't have time > until > tomorrow actually :/ > Still, here are some updates > > On Thu, Apr 6, 2023 at 2:32 AM David Malcolm > wrote: > > > On Wed, 2023-04-05 at 19:50

[Bug tree-optimization/35269] missed optimization of std::vector access.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #2 from AK

Re: PR target/70243: Do not generate fmaddfp and fnmsubfp

Hi! On Thu, Apr 06, 2023 at 11:12:11AM -0400, Michael Meissner wrote: > The Altivec instructions fmaddfp and fnmsubfp have different rounding > behaviors Those are not existing instructions. You mean "vmaddfp" etc. > than the VSX xvmaddsp and xvnmsubsp instructions. In particular, generating

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

Hi Alexandre! On 2023-04-05T23:38:43-0300, Alexandre Oliva via Gcc-patches wrote: > On Apr 5, 2023, Thomas Schwinge wrote: >> With... > >> Co-authored-by: Thomas Schwinge > >> ... added, I suppose. > > I wrote the patch based on your report, before even seeing your patch Eh, given your

[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #1 from AK --- Link to issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 where I derived the testcase from.

[Bug tree-optimization/109443] New: missed optimization of std::vector access (Related to issue 35269)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Bug ID: 109443 Summary: missed optimization of std::vector access (Related to issue 35269) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > With -std=c++11, started to ICE with r12-6326-ge948436eab818c527dd6. > With -std=c++14, started to ICE with r9-1483-g307193b82cecb8ab79cf. Yes that is

[Bug target/109435] overaligned structs are not passed correctly for mips64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/109442] New: Dead local copy of std::vector not removed from function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 Bug ID: 109442 Summary: Dead local copy of std::vector not removed from function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[patch] 'omp scan' struct block seq update for OpenMP 5.x

That's scheduled for GCC 13 and was found by Sandra and Frederik, 'omp scan' has undergone quite some transformation: In 5.0 it was added with a preceding and succeeding structured block. In 5.1, 'structured block' was replaced by 'structured-block-sequence' defined as "...a sequence of two or

[Bug c/86584] Incorrect -Wsequence-point warning on structure member

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584 --- Comment #2 from Andrew Pinski --- I think there is just a missing warning for the plain decl case and the structure member case is not a spurious warning.

[Bug c/86584] Incorrect -Wsequence-point warning on structure member

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584 oliver at futaura dot co.uk changed: What|Removed |Added CC||oliver at futaura dot co.uk

[Bug tree-optimization/109441] missed optimization when all elements of vector are known

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 --- Comment #1 from AK --- I guess a better test case is this: #include using namespace std; using T = int; T v(std::vector v) { T s; std::fill(v.begin(), v.end(), T()); for (auto i = 0; i < v.size(); ++i) { s += v[i];

[Bug tree-optimization/109441] missed optimization when all elements of vector are known

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization

[Bug tree-optimization/109440] Missed optimization of vector::at when a function is called inside the loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440 Andrew Pinski changed: What|Removed |Added Keywords||alias --- Comment #1 from Andrew

[Bug tree-optimization/109441] New: missed optimization when all elements of vector are known

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 Bug ID: 109441 Summary: missed optimization when all elements of vector are known Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW Priority|P3

[Bug tree-optimization/109440] New: Missed optimization of vector::at when a function is called inside the loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440 Bug ID: 109440 Summary: Missed optimization of vector::at when a function is called inside the loop Product: gcc Version: unknown Status: UNCONFIRMED

[committed][testsuite] arm: remove unused variables from test

Hi all, This is just a minor issue I found with a previous test of mine that caused it to fail in C++ mode due to these unused const variables being uninitialised. I forgot to remove these after removing some test cases that did use them. I removed the test cases, because I came to the

[Bug target/108177] MVE predicated stores to same address get optimized away

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177 --- Comment #5 from Stam Markianos-Wright --- With the fix to MVE auto_inc having gone in as ddc9b5ee13cd686c8674f92d46045563c06a23ea I have found that this fix keeps the auto-inc on these predicated stores broken. It seems to fail in

Ping: [PATCH v2][RFC] vect: Verify that GET_MODE_NUNITS is greater than one for vect_grouped_store_supported

May I ping this patch? https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614700.html Any suggestions and comments would be appreciated. Thank you! Sincerely, Kevin Lee

[Bug analyzer/109439] New: RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439 Bug ID: 109439 Summary: RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318 --- Comment #10 from Martin Jambor --- The problem is actually slightly different, I have just attached a possible fix to both to PR 107769.

[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769 --- Comment #7 from Martin Jambor --- Created attachment 54817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54817=edit potential patch I am testing the attached patch. I'd like to think about the whole situation a bit more next week,

[Bug analyzer/109438] New: Excessive Duplication of -Wanalyzer-out-of-bounds warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109438 Bug ID: 109438 Summary: Excessive Duplication of -Wanalyzer-out-of-bounds warnings Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug analyzer/109437] New: -Wanalyzer-out-of-bounds is emitted at most once per frame.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437 Bug ID: 109437 Summary: -Wanalyzer-out-of-bounds is emitted at most once per frame. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug c++/88061] section attributes of variable templates are ignored

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061 --- Comment #6 from Barry Revzin --- Any action on this one? A workaround right now is to change code that would ideally look like (which is pretty clean in my opinion): template void foo() { [[gnu::section(".meow")]] static int value =

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

Hi Eric, On 4/6/23 18:24, Eric Blake wrote: > On Wed, Apr 05, 2023 at 02:42:04AM +0200, Alejandro Colomar wrote: >> Hi Eric, >> >> I'm going to reply both your emails here so that GCC is CCed, and they can >> suggest better stuff. I'm worried about sending something to POSIX without >> enough

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

On Wed, Apr 05, 2023 at 02:42:04AM +0200, Alejandro Colomar wrote: > Hi Eric, > > I'm going to reply both your emails here so that GCC is CCed, and they can > suggest better stuff. I'm worried about sending something to POSIX without > enough eyes checking it. So this will be a long email.

[Bug target/109436] New: AArch64: suboptimal codegen in 128 bit constant stores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109436 Bug ID: 109436 Summary: AArch64: suboptimal codegen in 128 bit constant stores Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3

Re: [PATCH 2/3] RISC-V: Enable basic RVV auto-vectorization and support WHILE_LEN/LEN_LOAD/LEN_STORE pattern

Is changes for riscv-vsetvl.cc necessary for autovec? or is it additional optimization for the autovec use case? I would suggest splitting that if it's later one. And plz split out fixed-vlmax part into separated patch, that would be easier to review. On Thu, Apr 6, 2023 at 10:44 PM wrote: > >

Re: [RFC PATCH] driver: unfilter default library path [PR 104707]

Hello, On Thu, 6 Apr 2023, Shiqi Zhang wrote: > Currently, gcc delibrately filters out default library paths "/lib/" and > "/usr/lib/", causing some linkers like mold fails to find libraries. If linkers claim to be a compatible replacement for other linkers then they certainly should behave in

[Bug target/109402] v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402 --- Comment #2 from Mikael Pettersson --- Please send patches to gcc-patches for review.

[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:ddc9b5ee13cd686c8674f92d46045563c06a23ea commit r13-7114-gddc9b5ee13cd686c8674f92d46045563c06a23ea Author: Richard Earnshaw

Re: [PATCH] RISC-V: Add RVV auto-vectorization testcase

You included asm output by accidently :P On Thu, Apr 6, 2023 at 10:45 PM wrote: > > From: Juzhe-Zhong > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/rvv.exp: Add testing for RVV > auto-vectorization. > * gcc.target/riscv/rvv/vsetvl/vsetvl-17.c: Adapt testcase. >

[committed] arm: mve: fix auto-inc generation [PR107674]

My change r13-416-g485a0ae0982abe caused the compiler to stop generating auto-inc operations on mve loads and stores. The fix is to check whether there is a replacement register available when in strict mode and the register is still a pseudo. gcc: PR target/107674 *

PR target/70243: Do not generate fmaddfp and fnmsubfp

The Altivec instructions fmaddfp and fnmsubfp have different rounding behaviors than the VSX xvmaddsp and xvnmsubsp instructions. In particular, generating these instructions seems to break Eigen. GCC has generated the Altivec fmaddfp and fnmsubfp instructions on VSX systems as an alternative to

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #7 from LIU Hao --- clang generates 14 bytes: ``` mov rax, 0x7FFF # 48 B8 FF FF FF FF FF FF FF 7F and rax, rcx # 48 23 C1 ret # C3 `` but in principle this function requires

Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040]

On 4/6/23 04:31, Jakub Jelinek wrote: If we want to fix it in the combiner, I think the fix would be following. The optimization is about (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) and IMHO we can only optimize it into (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0) if we

[Bug target/109416] Missed constant propagation cases after reload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416 --- Comment #3 from Sinan --- Hi Andrew, Thank you for taking the time to explain the issue. I appreciate it. I think the issue between init/init2 and init3 might be different. Regarding init3, any 32-bit backend attempting to split a complex

Re: [PATCH] RISC-V: Fix regression of -fzero-call-used-regs=all

> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc > index 2e91d019f6c..90c69b52bb4 100644 > --- a/gcc/config/riscv/riscv-v.cc > +++ b/gcc/config/riscv/riscv-v.cc > @@ -43,6 +43,7 @@ > #include "optabs.h" > #include "tm-constrs.h" > #include "rtx-vector-builder.h" > +#include

Re: [PATCH] dse: Handle SUBREGs of word REGs differently for WORD_REGISTER_OPERATIONS targets [PR109040]

On 4/6/23 04:15, Eric Botcazou wrote: Originally I didn't really see this as an operation. But the more and more I ponder it feels like it's an operation and thus should be subject to WORD_REGISTER_OPERATIONS. While it's not really binding on RTL semantics, if we look at how some

Re: [PATCH] dse: Handle SUBREGs of word REGs differently for WORD_REGISTER_OPERATIONS targets [PR109040]

On 4/6/23 03:37, Li, Pan2 wrote: Yes, RISC-V riscv.h defined the WORD_REGISTER_OPERATIONS to be 1, while aarch64.h defined it as 0, with below comments. No idea this can fit RISC-V or not. I don't see any fundamental reason why it won't work. Most of the expansion code already has code

Re: [PATCH] dse: Handle SUBREGs of word REGs differently for WORD_REGISTER_OPERATIONS targets [PR109040]

On 4/6/23 03:31, Richard Sandiford wrote: Jeff Law writes: On 4/5/23 10:48, Jakub Jelinek wrote: On Wed, Apr 05, 2023 at 10:17:59AM -0600, Jeff Law wrote: It is true that an instruction like (insn 8 7 9 2 (set (reg:HI 141) (subreg:HI (reg:SI 142) 0)) "aauu.c":6:18 181

[PATCH] RISC-V: Add RVV auto-vectorization testcase

From: Juzhe-Zhong gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/rvv.exp: Add testing for RVV auto-vectorization. * gcc.target/riscv/rvv/vsetvl/vsetvl-17.c: Adapt testcase. * gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-1.c: New test. *

[PATCH 2/3] RISC-V: Enable basic RVV auto-vectorization and support WHILE_LEN/LEN_LOAD/LEN_STORE pattern

From: Juzhe-Zhong gcc/ChangeLog: * config/riscv/riscv-opts.h (enum riscv_autovec_preference_enum): Add compile option for RVV auto-vectorization. (enum riscv_autovec_lmul_enum): Ditto. * config/riscv/riscv-protos.h (get_vector_mode): Remove unused global function.

[PATCH 0/3] RISC-V:Enable basic auto-vectorization for RVV

From: Juzhe-Zhong PATCH 1: Add WHILE_LEN pattern in Loop Vectorizer to support decrement IV for RVV. PATCH 2: Enable basic auto-vectorization for RVV in RISC-V port. PATCH 3: Add testcases for basic RVV auto-vectorization of WHILE_LEN pattern includeing single rgroup test and multiple

[PATCH 1/3] VECT: Add WHILE_LEN pattern to support decrement IV manipulation for loop vectorizer.

From: Juzhe-Zhong This patch is to add WHILE_LEN pattern. It's inspired by RVV ISA simple "vvaddint32.s" example: https://github.com/riscv/riscv-v-spec/blob/master/example/vvaddint32.s More details are in "vect_set_loop_controls_by_while_len" implementation and comments. Consider such

Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040]

On 4/6/23 04:31, Jakub Jelinek wrote: As before, I unfortunately can't test it on riscv-linux (could perhaps try that on sparc-solaris on GCC Farm which is another WORD_REGISTER_OPERATIONS target, but last my bootstrap attempt there failed miserably because of the Don't bootstrap at

[Bug other/109435] [MIPS64R6] Typedef struct alignment returns incorrect results

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 --- Comment #1 from Jovan Dmitrović --- This is compile command that I used: mipsisa64r6-linux-gnuabi64-gcc -march=mips64r6 -mabi=64 -O0 -o foo foo.c -static I used the MIPS gcc package from Ubuntu's package repository. Also, I used

Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040]

> If the > (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) > to > (subreg:SI (and:HI (reg:HI xxx) (const_int 0x84c)) 0) > transformation is kosher for WORD_REGISTER_OPERATIONS, then I guess the > invalid operation is then in > simplify_context::simplify_binary_operation_1 > case AND: >

[Bug other/109435] New: [MIPS64R6] Typedef struct alignment returns incorrect results

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 Bug ID: 109435 Summary: [MIPS64R6] Typedef struct alignment returns incorrect results Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal

Re: [PATCH] riscv: Fix genrvv-type-indexer dependencies

LGTM, thanks :) On Thu, Apr 6, 2023 at 5:46 PM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > I've noticed > make: Circular build/genrvv-type-indexer.o <- gtype-desc.h dependency dropped. > > The following patch fixes that. The RTL_BASE_H variable includes a lot of > headers which the

[PATCH] gcov: add info about "calls" to JSON output format

Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed after stage1 opens? Thanks, Martin gcc/ChangeLog: * doc/gcov.texi: Document the new "calls" field and document the API bump. * gcov.cc (output_intermediate_json_line): Output

Re: [PATCH] RISC-V: Fix regression of -fzero-call-used-regs=all

--- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -7317,6 +7317,12 @@ riscv_shamt_matches_mask_p (int shamt, HOST_WIDE_INT mask) #undef TARGET_DWARF_POLY_INDETERMINATE_VALUE #define TARGET_DWARF_POLY_INDETERMINATE_VALUE riscv_dwarf_poly_indeterminate_value +namespace

[PATCH] RISC-V: Fix regression of -fzero-call-used-regs=all

From: Yanzhang Wang This patch registers a riscv specific function to TARGET_ZERO_CALL_USED_REGS instead of default in targhooks.cc. It will clean gpr and vector relevant registers. PR 109104 gcc/ChangeLog: * config/riscv/riscv-v.cc (default_zero_call_used_regs):

[Bug c++/107853] [10/11 Regression] variadic template with a variadic template friend with a requires of fold expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] variadic

[Bug c++/109425] mismatched argument pack lengths while expanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment

[Bug c++/109425] mismatched argument pack lengths while expanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 --- Comment #3 from Marek Polacek --- (In reply to Hannes Hauswedell from comment #2) > Thanks for the quick reply, and nice that it is already fixed for 13! > > I assume this will not be backported? It wouldn't be a huge problem, because > it

[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Marek Polacek changed: What|Removed |Added Keywords|needs-bisection | CC|

Re: [PATCH 1/7] openmp: Add Fortran support for "omp unroll" directive

Hi Thomas, On 01.04.23 10:42, Thomas Schwinge wrote: ... I see FAIL for x86_64-pc-linux-gnu '-m32' (thus, host, not offloading), '-O0' (only): [...] FAIL: libgomp.fortran/loop-transforms/unroll-1.f90 -O0 execution test [...] FAIL:

[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6

[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e commit r13-7113-g7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e Author: Andrew MacLeod Date:

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #6 from LIU Hao --- Looks like this has been fixed? https://gcc.godbolt.org/z/xP5E76aYz Despite that however, GCC generates suboptimal code that uses an XMM register to perform the bitwise AND operation.

[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-06 Known to fail|

Re: [PATCH] Add ssp_nonshared to link commandline for musl targets

On Thu, Apr 06, 2023 at 05:03:22PM +0530, Yash Shinde via Gcc-patches wrote: > When -fstack-protector options are enabled we need to > link with ssp_shared on musl since it does not provide > the __stack_chk_fail_local() so essentially it provides > libssp but not libssp_nonshared something like >

[PATCH] Search target sysroot gcc version specific dirs with multilib.

From: Khem Raj We install the gcc libraries (such as crtbegin.p) into //5.2.0/ which is a default search path for GCC (aka multi_suffix in the code below). is 'machine' in gcc's terminology. We use these directories so that multiple gcc versions could in theory co-exist on target. We only want

[PATCH] gcc: armv4: pass fix-v4bx to linker to support EABI.

The LINK_SPEC for linux gets overwritten by linux-eabi.h which means the value of TARGET_FIX_V4BX_SPEC gets lost and as a result the option is not passed to linker when chosing march=armv4 This patch redefines this in linux-eabi.h and reinserts it for eabi defaulting toolchains. Signed-off-by:

Re: [PATCH] combine: Fix simplify_comparison AND handling for WORD_REGISTER_OPERATIONS targets [PR109040]

On Thu, Apr 06, 2023 at 12:51:20PM +0200, Eric Botcazou wrote: > > If we want to fix it in the combiner, I think the fix would be following. > > The optimization is about > > (and:SI (subreg:SI (reg:HI xxx) 0) (const_int 0x84c)) > > and IMHO we can only optimize it into > > (subreg:SI (and:HI

[PATCH] Add ssp_nonshared to link commandline for musl targets

From: Khem Raj When -fstack-protector options are enabled we need to link with ssp_shared on musl since it does not provide the __stack_chk_fail_local() so essentially it provides libssp but not libssp_nonshared something like TARGET_LIBC_PROVIDES_SSP_BUT_NOT_SSP_NONSHARED where-as for glibc

[Bug c++/109434] New: std::optional weird -Wmaybe-unitialized and behaviour with -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434 Bug ID: 109434 Summary: std::optional weird -Wmaybe-unitialized and behaviour with -O2 Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal

Re: [aarch64] Use dup and zip1 for interleaving elements in initializing vector

On Thu, 6 Apr 2023 at 16:05, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford > > wrote: > >> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc > >> > b/gcc/config/aarch64/aarch64-sve-builtins-base.cc > >> > index

[Bug c/109426] Gcc runs into Infinite loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #6 from Jonathan Wakely --- It's a pattern with this person:

Re: -Wanalyzer-use-of-uninitialized-value always shadows -Wanalyzer-out-of-bounds

Hi David, I haven't yet looked into your suggestions, probably won't have time until tomorrow actually :/ Still, here are some updates On Thu, Apr 6, 2023 at 2:32 AM David Malcolm wrote: > On Wed, 2023-04-05 at 19:50 +0200, Benjamin Priour wrote: > > Hi David, > > > > I used the below code

[PATCH 2/3] RFC - match.pd: simplify debug dump checks

Hi All, Just sending these so people can test the series This is a small improvement in QoL codegen for match.pd to save time not re-evaluating the condition for printing debug information in every function. There is a small but consistent runtime and compile time win here. The runtime win

  1   2   >