[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org ---

Re: [PATCH v1] RISC-V: Support RVV VFMSAC rounding mode intrinsic API

ok juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-04 10:58 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang Subject: [PATCH v1] RISC-V: Support RVV VFMSAC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFMSAC for

Re: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API

ok juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-04 11:28 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang Subject: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFNMSAC

Re: [committed][RISC-V] Remove errant hunk of code

On 8/3/23 17:38, Vineet Gupta wrote: ;-)  Actually if you wanted to poke at zicond, the most interesting unexplored area I've come across is the COND_EXPR handling in gimple. When we expand a COND_EXPR into RTL the first approach we take is to try movcc in RTL. Unfortunately we don't

[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #14

[Bug modula2/110779] SysClock can not read the clock

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779 --- Comment #2 from Gaius Mulley --- Created attachment 55683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55683=edit Proposed fix Here is a proposed fix together with three regression tests.

[PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFNMSAC for the below samples. * __riscv_vfnmsac_vv_f32m1_rm * __riscv_vfnmsac_vv_f32m1_rm_m * __riscv_vfnmsac_vf_f32m1_rm * __riscv_vfnmsac_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

[PATCH v1] RISC-V: Support RVV VFMSAC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFMSAC for the below samples. * __riscv_vfmsac_vv_f32m1_rm * __riscv_vfmsac_vv_f32m1_rm_m * __riscv_vfmsac_vf_f32m1_rm * __riscv_vfmsac_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

[Bug libstdc++/110854] constructor of std::counting_semaphore is not constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #2 from

RE: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Friday, August 4, 2023 10:24 AM To: Li, Pan2 ; gcc-patches Cc: Kito.cheng ; Li, Pan2 ; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API LGTM.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625 --- Comment #20 from CVS Commits --- The master branch has been updated by Hao Liu : https://gcc.gnu.org/g:4d8b5563179f3a7ca268b64f71731a4878635497 commit r14-2973-g4d8b5563179f3a7ca268b64f71731a4878635497 Author: Hao Liu Date: Fri Aug 4

[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611 --- Comment #9 from Jiang An --- (In reply to Nikolas Klauser from comment #8) > I agree that the wording is a bit ambiguous, but GCC should decide on one > of them instead of returning different results between the type trait > builtins and

Re: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API

LGTM. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-04 10:22 To: gcc-patches CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang Subject: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the

[PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFNMACC for the below samples. * __riscv_vfnmacc_vv_f32m1_rm * __riscv_vfnmacc_vv_f32m1_rm_m * __riscv_vfnmacc_vf_f32m1_rm * __riscv_vfnmacc_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: *

Re: [PATCH 00/10] x86: (mainly) "prefix_extra" adjustments

On Thu, Aug 3, 2023 at 4:09 PM Jan Beulich via Gcc-patches wrote: > > Having noticed various bogus uses, I thought I'd go through and audit > them all. This is the result, with some other attributes also adjusted > as noticed in the process. (I think this tidying also is a good thing > to have

Re: [PATCH 08/10] x86: add missing "prefix" attribute to VF{,C}MULC

On Thu, Aug 3, 2023 at 4:16 PM Jan Beulich via Gcc-patches wrote: > > gcc/ > > * config/i386/sse.md > (__): Add > "prefix" attribute. > > (avx512fp16_sh_v8hf): > Likewise. Ok. > --- > Talking of "prefix": Shouldn't at least V32HF and V32BF have it also >

Re: [PATCH 10/10] x86: drop redundant "prefix_data16" attributes

On Thu, Aug 3, 2023 at 4:17 PM Jan Beulich via Gcc-patches wrote: > > The attribute defaults to 1 for TI-mode insns of type sselog, sselog1, > sseiadd, sseimul, and sseishft. > > In *v8hi3 [smaxmin] and *v16qi3 [umaxmin] also drop the > similarly stray "prefix_extra" at this occasion. These two

Re: [PATCH 07/10] x86: add (adjust) XOP insn attributes

On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches wrote: > > Many were lacking "prefix" and "prefix_extra", some had a bogus value of > 2 for "prefix_extra" (presumably inherited from their SSE5 counterparts, > which are long gone) and a meaningless "prefix_data16" one. Where > missing,

Re: [PATCH 09/10] x86: correct "length_immediate" in a few cases

On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches wrote: > > When first added explicitly in 3ddffba914b2 ("i386.md > (sse4_1_round2): Add avx512f alternative"), "*" should not have > been used for the pre-existing alternative. The attribute was plain > missing. Subsequent changes adding

Re: [PATCH 04/10] x86: "prefix_extra" can't really be "2"

On Thu, Aug 3, 2023 at 4:11 PM Jan Beulich via Gcc-patches wrote: > > In the three remaining instances separate "prefix_0f" and "prefix_rep" > are what is wanted instead. Ok. > > gcc/ > > * config/i386/i386.md (rdbase): Add "prefix_0f" and > "prefix_rep". Drop "prefix_extra". >

Re: [PATCH 06/10] x86: drop stray "prefix_extra"

On Thu, Aug 3, 2023 at 4:16 PM Jan Beulich via Gcc-patches wrote: > > While the attribute is relevant for legacy- and VEX-encoded insns, it is > of no relevance for EVEX-encoded ones. > > While there in avx512dq_broadcast_1 add > the missing "length_immediate". Ok. > > gcc/ > > *

Re: [PATCH 05/10] x86: replace/correct bogus "prefix_extra"

On Thu, Aug 3, 2023 at 4:14 PM Jan Beulich via Gcc-patches wrote: > > In the rdrand and rdseed cases "prefix_0f" is meant instead. For > mmx_floatv2siv2sf2 1 is correct only for the first alternative. For > the integer min/max cases 1 uniformly applies to legacy and VEX > encodings (the UB and SW

Re: [PATCH 03/10] x86: "ssemuladd" adjustments

On Thu, Aug 3, 2023 at 4:11 PM Jan Beulich via Gcc-patches wrote: > > They're all VEX3- (also covering XOP) or EVEX-encoded. Express that in > the default calculation of "prefix". FMA4 insns also all have a 1-byte > immediate operand. > > Where the default calculation is not sufficient /

Re: [PATCH 02/10] x86: "sse4arg" adjustments

On Thu, Aug 3, 2023 at 4:10 PM Jan Beulich via Gcc-patches wrote: > > Record common properties in other attributes' default calculations: > There's always a 1-byte immediate, and they're always encoded in a VEX3- > like manner (note that "prefix_extra" already evaluates to 1 in this > case). The

Re: [PATCH 01/10] x86: "prefix_extra" tidying

On Thu, Aug 3, 2023 at 4:10 PM Jan Beulich via Gcc-patches wrote: > > Drop SSE5 leftovers from both its comment and its default calculation. > A value of 2 simply cannot occur anymore. Instead extend the comment to > mention the use of the attribute in "length_vex", clarifying why >

RE: [PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Friday, August 4, 2023 6:22 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API LGTM

RE: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Friday, August 4, 2023 6:15 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API LGTM. I think you should go ahead to support and test

RE: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: 钟居哲 Sent: Friday, August 4, 2023 6:16 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API LGTM

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org,

[Bug target/84251] [11/12/13/14 Regression] Performance regression in gcc 8/9/10/11/12 when comparing floating point numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251 --- Comment #20 from Andrew Pinski --- Hmm: we have: ``` (jump_insn 8 7 9 2 (set (pc) (if_then_else (ordered (reg:CCFP 17 flags) (const_int 0 [0])) (label_ref 12) (pc))) "/app/example.cpp":5:6 1055

[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666 --- Comment #13 from Andrew Pinski --- I don't know if this could help here but combine does produce: Trying 37, 34 -> 38: 37: flags:CCGC=cmp(r82:SI,0x7f) REG_DEAD r82:SI 34: {r92:DI=r87:DI+r89:DI;clobber flags:CC;} REG_DEAD

Re: [PATCH] Replace invariant ternlog operands

On Fri, Aug 4, 2023 at 1:30 AM Alexander Monakov wrote: > > > On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote: > > > > +;; If the first and the second operands of ternlog are invariant and ;; > > > +the third operand is memory ;; then we should add load third operand > > > +from memory to

[Bug rtl-optimization/82454] Possible future performance regression in x86 for 64-bit constant expansions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82454 --- Comment #5 from Andrew Pinski --- Actually this looks almost exactly the same as PR 82339 .

[Bug rtl-optimization/82454] Possible future performance regression in x86 for 64-bit constant expansions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82454 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-10-09 00:00:00 |2023-8-3 See Also|

[Bug tree-optimization/82446] [11/12/13/14 Regression] Missed equalities in dr_group_sort_cmp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82446 --- Comment #11 from Andrew Pinski --- Is this still true?

Re: [committed][RISC-V] Remove errant hunk of code

On 8/3/23 16:15, Jeff Law wrote: On 8/3/23 16:26, Vineet Gupta wrote: As discussed in Tue call, I definitely have 1 fix to riscv_rtx_costs (), which is worth pondering. It adjusts the cost of consts and helps Hoist GCSE constants (which granted kicks in only at -Os). However it does

[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611 --- Comment #8 from Nikolas Klauser --- I agree that the wording is a bit ambiguous, but GCC should decide on one of them instead of returning different results between the type trait builtins and the noexcept operator.

[Bug target/110897] RISC-V: Fail to vectorize shift

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #2 from JuzheZhong --- Yes, (In reply to Andrew Pinski from comment #1) > Does the riscv backend support uint32_t shifting? How about extending and > contracting to/from uint16_t to uint32_t? Yes, RISC-V port support uint32_t

[Bug target/110897] RISC-V: Fail to vectorize shift

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #1 from Andrew Pinski --- Does the riscv backend support uint32_t shifting? How about extending and contracting to/from uint16_t to uint32_t?

[Bug c/110897] New: RISC-V: Fail to vectorize shift

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 Bug ID: 110897 Summary: RISC-V: Fail to vectorize shift Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

Re: [committed][RISC-V] Remove errant hunk of code

On 8/3/23 16:26, Vineet Gupta wrote: As discussed in Tue call, I definitely have 1 fix to riscv_rtx_costs (), which is worth pondering. It adjusts the cost of consts and helps Hoist GCSE constants (which granted kicks in only at -Os). However it does affect codegen in subtle ways since

[Bug c++/110894] [modules] Program terminates with signal SIGSEGV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 --- Comment #3 from Johel Ernesto Guerrero Peña --- Reduced: . If you comment out the use of `.data()` at the end of `my_string_view.hpp` it works. It originally comes from ``'s specialization of `hash`, `

[Bug other/110895] [14 regression] ICE compiling gcc.c-torture/compile/pr33133.c after r14-2925-g2bae476b511dc4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110895 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110874 Andrew Pinski changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment

[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 81981, which changed state. Bug 81981 Summary: [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981 What|Removed

[Bug tree-optimization/110896] [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is xfailed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110896 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4

[Bug tree-optimization/110896] New: [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is xfailed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110896 Bug ID: 110896 Summary: [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is xfailed Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic, xfail

[Bug other/110895] New: [14 regression] ICE compiling gcc.c-torture/compile/pr33133.c after r14-2925-g2bae476b511dc4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110895 Bug ID: 110895 Summary: [14 regression] ICE compiling gcc.c-torture/compile/pr33133.c after r14-2925-g2bae476b511dc4 Product: gcc Version: 14.0

gcc-11-20230803 is now available

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

Re: [committed][RISC-V] Remove errant hunk of code

On 8/3/23 11:12, Jeff Law via Gcc-patches wrote: On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: [...] There's a bigger TODO in this space WRT a top-to-bottom evaluation of the costing on RISC-V.  I'm still formulating what that evaluation is going to look like, so

Re: [PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-03 22:38 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFMACC

Re: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-03 13:28 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFWMUL

Re: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API

LGTM. I think you should go ahead to support and test all api. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-03 11:29 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding mode intrinsic API From: Pan Li

[Bug target/80491] [11/12/13/14 Regression] Compiler regression for long-add case.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491 --- Comment #25 from Andrew Pinski --- Hmm, I thought Jakub's recent work on PR 79173 would have fixed this but no it didn't.

Re: One question on the source code of tree-object-size.cc

So, the basic question is: Given the following: struct fix { int others; int array[10]; } extern struct fix * alloc_buf (); int main () { struct fix *p = alloc_buf (); __builtin_object_size(p->array,0) == ? } Given p->array, can the compiler determine that p points to an object that

[Bug tree-optimization/79534] [11/12/13/14 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534 --- Comment #22 from Andrew Pinski --- For the original testcase, since GCC 13, ifcombine does not combine the ifs. I have not looked into why though.

[Bug tree-optimization/102556] equality comparison of a [static N] parameter to null not folded

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102556 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #2

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110878 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110892 Edwin Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110892 --- Comment #3 from Patrick O'Neill --- These failures are fixed as of d61efa3cd3378be38738bfb5139925d1505c1325 Confirmed using rv32 newlib. https://github.com/patrick-rivos/riscv-gnu-toolchain/issues/139

Re: RISC-V: Added support for CRC.

On 8/3/23 13:37, Mariam Harutyunyan via Gcc-patches wrote: This patch adds CRC support for the RISC-V architecture. It adds internal functions and built-ins specifically designed to handle CRC computations efficiently. If the target is ZBC, the clmul instruction is used for the CRC code

Update estimated iteraitons counts after splitting

Hi, Hmmer's internal function has 4 loops. The following is the profile at start: loop 1: estimate 472 iterations by profile: 473.497707 (reliable) count in:84821 (precise, freq 0.9979) loop 2: estimate 99 iterations by profile: 100.00 (reliable) count in:39848881

Fix profiledbootstrap

Hi, Profiledbootstrap fails with ICE in update_loop_exit_probability_scale_dom_bbs called from loop unroling. The reason is that under relatively rare situations, we may run into case where loop has multiple exits and all are considered as likely but then we scale down the profile and one of the

[Bug middle-end/110857] aarch64-linux-gnu profiledbootstrap broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110857 --- Comment #3 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:93236ad9e8fa9208e754e8806dc369e1a79dbdf7 commit r14-2966-g93236ad9e8fa9208e754e8806dc369e1a79dbdf7 Author: Jan Hubicka Date: Thu

Re: [PATCH v3] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 8/1/23 19:38, Xiao Zeng wrote: This patch recognizes Zicond patterns when the select pattern with condition eq or neq to 0 (using eq as an example), namely: 1 rd = (rs2 == 0) ? non-imm : 0 2 rd = (rs2 == 0) ? non-imm : non-imm 3 rd = (rs2 == 0) ? reg : non-imm 4 rd = (rs2 == 0) ? reg : reg

Re: RISC-V: Added support for CRC.

Hi. Thank you. I'll add. Best regards, Mariam On Thu, Aug 3, 2023, 23:56 Andrew Pinski wrote: > On Thu, Aug 3, 2023 at 12:38 PM Mariam Harutyunyan via Gcc-patches > wrote: > > > > This patch adds CRC support for the RISC-V architecture. It adds internal > > functions and built-ins

Re: RISC-V: Added support for CRC.

On Thu, Aug 3, 2023 at 12:38 PM Mariam Harutyunyan via Gcc-patches wrote: > > This patch adds CRC support for the RISC-V architecture. It adds internal > functions and built-ins specifically designed to handle CRC computations > efficiently. > > If the target is ZBC, the clmul instruction is used

Re: One question on the source code of tree-object-size.cc

> On Aug 3, 2023, at 1:51 PM, Kees Cook wrote: > > On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote: >> One thing I need to point out first is, currently, even for regular fixed >> size array in the structure, >> We have this same issue, for example: >> >> #define LENGTH 10 >> >> struct

[Bug c++/110894] [modules] Program terminates with signal SIGSEGV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 Andrew Pinski changed: What|Removed |Added URL|https://cpp2.godbolt.org/z/ | |7YrvenrzT

[Bug c++/110893] [modules] ICE Segmentation fault during GIMPLE pass modref

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110893 Andrew Pinski changed: What|Removed |Added URL|https://cpp2.godbolt.org/z/ | |8q9c3P6vY

[Bug c++/110894] [modules] Program terminates with signal SIGSEGV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 --- Comment #1 from Johel Ernesto Guerrero Peña --- If instead I use `std::string_view` in `-O3` (`-O0` works), it also diagnoses (): ``` In file included from /app/module.cpp:2, of module hello, imported

RISC-V: Added support for CRC.

This patch adds CRC support for the RISC-V architecture. It adds internal functions and built-ins specifically designed to handle CRC computations efficiently. If the target is ZBC, the clmul instruction is used for the CRC code generation; otherwise, table-based CRC is generated. A table with

[Bug c++/110894] New: [modules] Program terminates with signal SIGSEGV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110894 Bug ID: 110894 Summary: [modules] Program terminates with signal SIGSEGV Product: gcc Version: 14.0 URL: https://cpp2.godbolt.org/z/7YrvenrzT Status: UNCONFIRMED

[Bug c++/110893] New: [modules] ICE Segmentation fault during GIMPLE pass modref

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110893 Bug ID: 110893 Summary: [modules] ICE Segmentation fault during GIMPLE pass modref Product: gcc Version: 14.0 URL: https://cpp2.godbolt.org/z/8q9c3P6vY

[PATCH] Specify signed/unsigned/dontcare in calls to extract_bit_field_1.

This patch is inspired by Jakub's work on PR rtl-optimization/110717. The bitfield example described in comment #2, looks like: struct S { __int128 a : 69; }; unsigned type bar (struct S *p) { return p->a; } which on x86_64 with -O2 currently generates: bar:movzbl 8(%rdi), %ecx

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

Pushed to upstream master. Thanks ! Jose E. Marchesi writes: > OK. > Thanks. > >> Hi, >> >> Resending this patch since I have noticed I had a testcase added in >> previous patch. Makes more sense here. >> >> Thanks, >> Cupertino >> >> From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Pushed to upstream master. Thanks ! Jose E. Marchesi writes: > Ok. > Thanks! > >> From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 >> From: Cupertino Miranda >> Date: Thu, 6 Apr 2023 15:22:48 +0100 >> Subject: [PATCH v2 1/2] bpf: Implementation of BPF CO-RE builtins >>

[Bug target/107479] bpf: add __builtin_btf_type_id

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107479 --- Comment #1 from CVS Commits --- The master branch has been updated by Cupertino Miranda : https://gcc.gnu.org/g:e0a81559c198153923f0a1a3be7c25df545f3964 commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964 Author: Cupertino Miranda

[Bug target/107480] bpf: add __builtin_preserve_type_info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107480 --- Comment #1 from CVS Commits --- The master branch has been updated by Cupertino Miranda : https://gcc.gnu.org/g:e0a81559c198153923f0a1a3be7c25df545f3964 commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964 Author: Cupertino Miranda

[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 --- Comment #6 from CVS Commits --- The master branch has been updated by Cupertino Miranda : https://gcc.gnu.org/g:e0a81559c198153923f0a1a3be7c25df545f3964 commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964 Author: Cupertino Miranda

[Bug target/107481] bpf: add __builtin_preserve_enum_value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107481 --- Comment #1 from CVS Commits --- The master branch has been updated by Cupertino Miranda : https://gcc.gnu.org/g:e0a81559c198153923f0a1a3be7c25df545f3964 commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964 Author: Cupertino Miranda

Re: [PATCH] [libbacktrace] fix up broken test

On Thu, Aug 3, 2023 at 6:27 AM Richard Biener via Gcc-patches wrote: > > zstdtest has some inline data where some testcases lack the > uncompressed length field. Thus it computes that but still > ends up allocating memory for the uncompressed buffer based on > that (zero) length. Oops. Causes

[COMMITTED] Add operand ranges to op1_op2_relation API.

We're looking to add the unordered relations for floating point, and as a result, we can no longer determine the relation between op1 and op2 in a statement based purely on the LHS... we also need to know the type of the operands on the RHS. This patch adjusts op1_op2_relation to fit the same

[COMMITTED] Provide a routine for NAME == NAME relation.

We've been assuming x == x is always VREL_EQ in GORI, but this is not always going to be true with floating point.  Provide an API to return the relation. Bootstraps on  x86_64-pc-linux-gnu with no regressions.   Pushed. Andrew From 430ff4f3e670e02185991190a5e2d90e61b39e07 Mon Sep 17 00:00:00

[COMMITTED] Automatically set type is certain Value_Range routines.

When you use a Value_Range, you need to set it's type first so it knows whether it will be an irange or an frange or whatever. There are a few set routines which take a type, and you shouldn't need to set the type first in those cases..  For instance set_varying() takes a type, so it seems

Re: [PATCH] Read global value/mask in IPA.

On 7/31/23 18:47, Martin Jambor wrote: Hello, On Tue, Jul 18 2023, Aldy Hernandez wrote: On 7/17/23 15:14, Aldy Hernandez wrote: Instead of reading the known zero bits in IPA, read the value/mask pair which is available. There is a slight change of behavior here. I have removed the check

Re: [committed][RISC-V] Remove errant hunk of code

On 8/3/23 11:41, Palmer Dabbelt wrote: On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: I'm using this hunk locally to more thoroughly exercise the zicond paths due to inaccuracies elsewhere in the costing model.  It was never supposed to be part of the costing

[Bug tree-optimization/77568] [11/12/13/14 regression] CSE/PRE/Hoisting blocks common instruction contractions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77568 --- Comment #20 from Andrew Pinski --- (In reply to Wilco from comment #0) > void f3(char *p, int x) > { > if (x & 1) p[0] = 0; > if (x & 2) p[1] = 0; > if (x & 4) p[2] = 0; > if (x & 8) p[2] = 0; > g(0,0); > if (x & 1) p[3] = 0; >

Re: One question on the source code of tree-object-size.cc

On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote: >One thing I need to point out first is, currently, even for regular fixed size >array in the structure, >We have this same issue, for example: > >#define LENGTH 10 > >struct fix { > size_t foo; > int array[LENGTH]; >}; > >… >int main () >{ >

Re: [committed][RISC-V] Remove errant hunk of code

On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: I'm using this hunk locally to more thoroughly exercise the zicond paths due to inaccuracies elsewhere in the costing model. It was never supposed to be part of the costing commit though. And as we've seen it's causing

Re: One question on the source code of tree-object-size.cc

One thing I need to point out first is, currently, even for regular fixed size array in the structure, We have this same issue, for example: #define LENGTH 10 struct fix { size_t foo; int array[LENGTH]; }; … int main () { struct fix *p; p = alloc_buf_more ();

RE: [PATCH] Replace invariant ternlog operands

On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote: > > +;; If the first and the second operands of ternlog are invariant and ;; > > +the third operand is memory ;; then we should add load third operand > > +from memory to register and ;; replace first and second operands with > > +this

Re: [PATCH] Add documentation for -Wflex-array-member-not-at-end.

On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote: > +@opindex Wflex-array-member-not-at-end > +@opindex Wno-flex-array-member-not-at-end > +@item -Wflex-array-member-not-at-end I'd expect this to have @r{(C and C++ only)} to indicate what languages the option applies to. OK with that

Re: [PATCH] c-family: Add _BitInt support for __atomic_*fetch* [PR102989]

On Thu, 3 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > --- gcc/testsuite/gcc.dg/bitint-18.c.jj 2023-08-03 12:26:35.510922996 > +0200 > +++ gcc/testsuite/gcc.dg/bitint-18.c 2023-08-03 12:26:42.114831050 +0200 > @@ -0,0 +1,44 @@ > +/* PR c/102989 */ > +/* { dg-do compile { target bitint

Re: One question on the source code of tree-object-size.cc

On 2023-08-03 12:43, Qing Zhao wrote: Surely we could emit that for __bdos(q->array, 0) though, couldn't we? For __bdos(q->array, 0), we only have the access info for the sub-object q->array, we can surely decide the size of the sub-object q->array, but we still cannot decide the whole

[Bug c++/110158] Cannot use union with std::string inside in constant expression

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

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728 --- Comment #12 from John McCall --- While it's theoretically possible to split a computed-goto edge, in practice you want to avoid doing so if you at all can, because the split-edge pattern defeats the interpreter optimization that's the

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110892 --- Comment #2 from Patrick O'Neill --- Seems like a fix was pushed: https://inbox.sourceware.org/gcc-patches/89dfe3c2-ef96-3000-de87-74ff83354...@gmail.com/T/#m09608208a2dcc2bbf88a4f3419b062b4b4b349c5 We'll test it and update the issue once

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110892 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords|

  1   2   3   >