[PATCHv2] Fix PR 110874: infinite loop in gimple_bitwise_inverted_equal_p with fre

This changes gimple_bitwise_inverted_equal_p to use a 2 different match patterns to try to match bit_not wrapped with a possible nop_convert and a comparison also wrapped with a possible nop_convert. This is to avoid being recursive. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressi

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

> On Aug 3, 2023, at 12:15 PM, Siddhesh Poyarekar wrote: > > On 2023-08-02 10:02, Qing Zhao wrote: >> /*when checking the observed access p->array, we only have info on the >> observed access, i.e, the TYPE_SIZE info from the access. We don't have >> info on the whole object. */ >>

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 objec

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

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 reg

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 (); expect(__builtin_object_

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 pr

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

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 f

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

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

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 m

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

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

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

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 25

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 f

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

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

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 ex

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

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 gener

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 ha

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 Th

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 fo

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 fo

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

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 CSE

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 aff

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

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 juzhe.zh...@rivai.ai

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 al

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 juzhe.zh...@rivai.ai

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

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 d

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

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 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/ > > * config/i3

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

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

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

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 ahe

[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: * config/riscv/r

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 VFNMACC

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

[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: * config/riscv/riscv-

[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: * config/riscv/r

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 crea

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 fo

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 VFMSAC rounding mode intrinsic API

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

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

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

[C PATCH] _Generic should not warn in non-active branches [PR68193,PR97100]

Here is a patch to reduce false positives in _Generic. Bootstrapped and regression tested on x86_64-linux. Martin c: _Generic should not warn in non-active branches [PR68193,PR97100] To avoid false diagnostics, use c_inhibit_evaluation_warnings when a generic association is k

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

From: Pan Li This patch would like to support the rounding mode API for the VFMADD as the below samples. * __riscv_vfmadd_vv_f32m1_rm * __riscv_vfmadd_vv_f32m1_rm_m * __riscv_vfmadd_vf_f32m1_rm * __riscv_vfmadd_vf_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-v

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

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

Re: Fix profile upate after vectorizer peeling

On Thu, Aug 3, 2023 at 5:12 PM Aldy Hernandez wrote: > > > > On 8/3/23 16:29, Jeff Law wrote: > > > > > > On 8/3/23 08:23, Jan Hubicka wrote: > Jeff, an help would be appreciated here :) > > I will try to debug this. One option would be to disable branch > prediciton on vect_c

Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop.

On Thu, Aug 3, 2023 at 5:21 PM Jeff Law wrote: > > > > On 8/3/23 01:04, Richard Biener wrote: > > On Wed, Aug 2, 2023 at 4:08 PM Manolis Tsamis > > wrote: > >> > >> Hi all, > >> > >> I'm pinging to discuss again if we want to move this forward for GCC14. > >> > >> I did some testing again and I

Re: [PATCH] mid-end: Use integral time intervals in timevar.cc

On Thu, 3 Aug 2023, Matthew Malcomson wrote: > > > > I think this is undesriable. With fused you mean we use FMA? > > I think you could use -ffp-contract=off for the TU instead. > > > > Note you can't use __attribute__((noinline)) literally since the > > host compiler might not support this. >

Re: [PATCHv2] Fix PR 110874: infinite loop in gimple_bitwise_inverted_equal_p with fre

On Thu, Aug 3, 2023 at 6:41 PM Andrew Pinski via Gcc-patches wrote: > > This changes gimple_bitwise_inverted_equal_p to use a 2 different match > patterns > to try to match bit_not wrapped with a possible nop_convert and a comparison > also wrapped with a possible nop_convert. This is to avoid be

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

On Thu, Aug 3, 2023 at 9:15 PM Roger Sayle wrote: > > > 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

<    1   2