Re: [PATCH v1] Match: Extract integer_types_ternary_match helper to avoid code dup [NFC]

2024-05-18 Thread Andrew Pinski
On Sat, May 18, 2024, 9:17 PM wrote: > From: Pan Li > > There are sorts of match pattern for SAT related cases, there will be > some duplicated code to check the dest, op_0, op_1 are same tree types. > Aka ternary tree type matches. Thus, extract one helper function to > do this and avoid

[PATCH v1] Match: Extract integer_types_ternary_match helper to avoid code dup [NFC]

2024-05-18 Thread pan2 . li
From: Pan Li There are sorts of match pattern for SAT related cases, there will be some duplicated code to check the dest, op_0, op_1 are same tree types. Aka ternary tree type matches. Thus, extract one helper function to do this and avoid match code duplication. The below test suites are

[to-be-committed][RISC-V][PR target/115142] Do not create invalidate shift-add insn

2024-05-18 Thread Jeff Law
Repost, this time with the RISC-V tag so it's picked up by the CI system. This fixes a minor bug that showed up in the CI system, presumably with fuzz testing. Under the right circumstances, we could end trying to emit a shift-add style sequence where the to-be-shifted operand was not a

RE: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes

2024-05-18 Thread Li, Pan2
Hi Botcazou, Just notice that this patch may result in some ICE when build libc++ for the riscv port, details as below. Please note not all configuration can reproduce this issue, feel free to ping me if you cannot reproduce this issue. CC more riscv port people for awareness. during GIMPLE

[PATCH] PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143]

2024-05-18 Thread Andrew Pinski
The problem here is even if last_and_only_stmt returns a statement, the bb might still contain a phi node which defines a ssa name which is used in that statement so we need to add a check to make sure that the phi nodes are empty for the middle bbs in both the `CMP?MINMAX:MINMAX` case and the

[to-be-committed][PR target/115142] Do not create invalidate shift-add insn

2024-05-18 Thread Jeff Law
This fixes a minor bug that showed up in the CI system, presumably with fuzz testing. Under the right circumstances, we could end trying to emit a shift-add style sequence where the to-be-shifted operand was not a register. This naturally leads to an unrecognized insn. The circumstances

[C PATCH] Fix for redeclared enumerator initialized with different type [PR115109]

2024-05-18 Thread Martin Uecker
Bootstrapped and regression tested on x86_64 c23: Fix for redeclared enumerator initialized with different type [PR115109] c23 specifies that the type of a redeclared enumerator is the one of the previous declaration. Convert initializers with different type accordingly

Re: [PATCH] Optab: add isfinite_optab for __builtin_isfinite

2024-05-18 Thread Andrew Pinski
On Thu, Apr 11, 2024 at 8:07 PM HAO CHEN GUI wrote: > > Hi, > This patch adds an optab for __builtin_isfinite. The finite check can be > implemented on rs6000 by a single instruction. It needs an optab to be > expanded to the certain sequence of instructions. > > The subsequent patches will

Re: [PATCH] Optab: add isnormal_optab for __builtin_isnormal

2024-05-18 Thread Andrew Pinski
On Fri, Apr 12, 2024 at 1:10 AM HAO CHEN GUI wrote: > > Hi, > This patch adds an optab for __builtin_isnormal. The normal check can be > implemented on rs6000 by a single instruction. It needs an optab to be > expanded to the certain sequence of instructions. > > The subsequent patches will

Re: [C PATCH] Fix for some variably modified types not being recognized [PR114831]

2024-05-18 Thread Martin Uecker
(correct email) > We did not propagate C_TYPE_VARIABLY_MODIFIED to pointers in all > cases.   I added this directly in two places, but maybe we should > check all cases of build_pointer_type or integrate this into  > c_build_pointer_type and use this everywhere (but I do not fully  > understand

[C PATCH] Fix for some variably modified types not being recognized [PR114831]

2024-05-18 Thread Martin Uecker
We did not propagate C_TYPE_VARIABLY_MODIFIED to pointers in all cases.   I added this directly in two places, but maybe we should check all cases of build_pointer_type or integrate this into  c_build_pointer_type and use this everywhere (but I do not fully  understand the pointer mode logic

[patch,avr,applied] PR115065: Tweak __clzhi2

2024-05-18 Thread Georg-Johann Lay
Applied as obvious, Johann -- Author: Wolfgang Hospital Date: Sat May 18 15:02:51 2024 +0200 AVR: target/115065 - Tweak __clzhi2. The libgcc implementation of __clzhi2 can be tweaked by one cycle in some situations by re-arranging the instructions. It also reduces the WCET

[pushed] wwwdocs: egcs-1.1: Use 64-bit instead of 64 bit

2024-05-18 Thread Gerald Pfeifer
Another instance I found. With that wwwdocs should be consistent. Pushed. Gerald --- htdocs/egcs-1.1/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/egcs-1.1/index.html b/htdocs/egcs-1.1/index.html index 5db4e342..a62ed3df 100644 ---

Re: [Patch, aarch64] v6: Preparatory patch to place target independent and,dependent changed code in one file

2024-05-18 Thread Ajit Agarwal
Hello Alex: On 16/05/24 10:21 pm, Alex Coplan wrote: > Hi Ajit, > > Thanks a lot for working through the review feedback. > > The patch LGTM with the two minor suggested changes below. I can't > approve the patch, though, so you'll need an OK from Richard S. > > Also, I'm not sure if it makes

Re: [Patch, aarch64] v6: Preparatory patch to place target independent and,dependent changed code in one file

2024-05-18 Thread Ajit Agarwal
Hello Richard: On 17/05/24 11:07 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >> Hello Alex/Richard: >> >> All review comments are addressed. >> >> Common infrastructure of load store pair fusion is divided into target >> independent and target dependent changed code. >> >> Target

[Patch, aarch64] v7: Preparatory patch to place target independent and dependent changed code in one file

2024-05-18 Thread Ajit Agarwal
Hello Alex/Richard: All comments are addressed. Common infrastructure of load store pair fusion is divided into target independent and target dependent changed code. Target independent code is the Generic code with pure virtual function to interface between target independent and dependent

Re: [PATCH] libstdc++: increment *this instead of this

2024-05-18 Thread Kefu Chai
On Sat, May 18, 2024 at 3:25 PM Jakub Jelinek wrote: > On Sat, May 18, 2024 at 02:53:20PM +0800, Kefu Chai wrote: > > libstdc++-v3/ChangeLog: > > > > * include/bits/unicode.h (enable_borrowed_range): Call ++(*this) > > instead of ++this > > This should be already fixed, see

Re: [PATCH] libstdc++: increment *this instead of this

2024-05-18 Thread Jakub Jelinek
On Sat, May 18, 2024 at 02:53:20PM +0800, Kefu Chai wrote: > libstdc++-v3/ChangeLog: > > * include/bits/unicode.h (enable_borrowed_range): Call ++(*this) > instead of ++this This should be already fixed, see https://gcc.gnu.org/PR115119 Jakub

[PATCH] libstdc++: increment *this instead of this

2024-05-18 Thread Kefu Chai
From: Kefu Chai in _Grapheme_cluster_view::_Iterator, we implement its post-increment operator (a++) using its pre-increment opereator (++a). but we use ++this to call the pre-increment opereator in the implementation of the post-increment operator. one cannot assign to `this`. both GCC and