Re: [PATCH] Optab: add isfinite_optab for __builtin_isfinite

Hi Andrew, 在 2024/5/19 3:42, Andrew Pinski 写道: > This is missing adding documentation for the new optab. > It should be documented in md.texi under `Standard Pattern Names For > Generation` section. Thanks for your reminder. I will add ones for all patches. Thanks Gui Haochen

[PATCH V3] report message for operator %a on unaddressible operand

Hi, For PR96866, when printing asm code for modifier "%a", an addressable operand is required. While the constraint "X" allow any kind of operand even which is hard to get the address directly. e.g. extern symbol whose address is in TOC. An error message would be reported to indicate the invalid

Re: [PATCH v5 1/5] Improve must tail in RTL backend

On Tue, May 14, 2024 at 04:15:08PM +0200, Richard Biener wrote: > On Sun, May 5, 2024 at 8:16 PM Andi Kleen wrote: > > > > - Give error messages for all causes of non sibling call generation > > - Don't override choices of other non sibling call checks with > > must tail. This causes ICEs. The

[PATCH-3v2, rs6000] Implement optab_isnormal for SFDF and IEEE128

Hi, This patch implemented optab_isnormal for SFDF and IEEE128 by test data class instructions. Compared with previous version, the main change is not to test if pseudo can be created in expand and modify dg-options and dg-finals of test cases according to reviewer's advice.

[PATCH-2v2, rs6000] Implement optab_isfinite for SFDF and IEEE128

Hi, This patch implemented optab_isfinite for SFDF and IEEE128 by test data class instructions. Compared with previous version, the main change is not to test if pseudo can be created in expand and modify dg-options and dg-finals of test cases according to reviewer's advice.

[PATCH-1v2, rs6000] Implement optab_isinf for SFDF and IEEE128

Hi, This patch implemented optab_isinf for SFDF and IEEE128 by test data class instructions. Compared with previous version, the main change is to modify the dg-options and dg-finals of test cases according to reviewer's advice. https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648304.html

Re: [PATCH 0/2] Align tight loops to solve cross cacheline issue

On Wed, May 15, 2024 at 11:30 AM Jiang, Haochen wrote: > > Also cc Honza and Richard since we touched generic tune. > > Thx, > Haochen > > > -Original Message- > > From: Haochen Jiang > > Sent: Wednesday, May 15, 2024 11:04 AM > > To: gcc-patches@gcc.gnu.org > > Cc: Liu, Hongtao ;

[r15-579 Regression] FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) on Linux/x86_64

On Linux/x86_64, a9251ab3c91c8c559d0306838575a666ae62dff4 is the first bad commit commit a9251ab3c91c8c559d0306838575a666ae62dff4 Author: Richard Biener Date: Thu May 16 12:35:28 2024 +0200 wrong code with points-to and volatile caused with GCC configured with ../../gcc/configure

Re: [PATCH] i386: Rename sat_plusminus expanders to standard names [PR11260]

On Fri, May 17, 2024 at 3:55 PM Uros Bizjak wrote: > > Rename _3 expander to a standard ssadd, > usadd, sssub and ussub name to enable corresponding optab expansion. > > Also add named expander for MMX modes. LGTM. > > PR middle-end/112600 > > gcc/ChangeLog: > > * config/i386/mmx.md (3):

Re: [PATCH 4/13] rs6000, extend the current vec_{un,}signed{e,o} built-ins

Hi Carl, on 2024/5/18 04:20, Carl Love wrote: > Kewen: > > I am working thru the patches. I made the changes as requested for this > patch but have a question about > one of your comments. > > On 5/14/24 00:53, Kewen.Lin wrote: >> Hi, >> >> on 2024/4/20 05:17, Carl Love wrote: >>> rs6000,

RE: [PATCH v4] DSE: Fix ICE after allow vector type in get_stored_val

Committed, thanks Jeff. Let's wait for a while before backporting. Pan -Original Message- From: Jeff Law Sent: Monday, May 20, 2024 12:23 AM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Liu, Hongtao ; richard.guent...@gmail.com Subject: Re:

Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

On 5/19/24 02:01, Tobias Burnus wrote: I noticed that gfortran's coarray support did not link to the http://www.opencoarrays.org/ > [snip] diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi index 40e8e4a7cdd..78a2910b8d8 100644 --- a/gcc/fortran/invoke.texi +++

Re: [to-be-committed][RISC-V] Eliminate redundant bitmanip operation

On 5/19/24 1:59 PM, Andrew Pinski wrote: On Sun, May 19, 2024 at 10:58 AM Jeff Law wrote: perl has some internal bitmap code. One of its implementation properties is that if you ask it to set a bit, the bit is first cleared. Unfortunately this is fairly hard to see in gimple/match due

Re: [pshed] testsuite, C++, Darwin: Skip cxa_atexit-6, which is not applicable.

On Sun, May 19, 2024 at 6:38 AM Iain Sandoe wrote: > > As per the analysis in the PR, tested on x86_64, i686 and aarch64 Darwin > (and on x86_64 linux), pushed to trunk, thanks, > Iain Thanks for doing this. Thanks, Andrew > > --- 8< --- > > For Darwin, non-weak functions defined in a TU

Re: [to-be-committed][RISC-V] Eliminate redundant bitmanip operation

On Sun, May 19, 2024 at 10:58 AM Jeff Law wrote: > > perl has some internal bitmap code. One of its implementation > properties is that if you ask it to set a bit, the bit is first cleared. > > > Unfortunately this is fairly hard to see in gimple/match due to type > changes in the IL. But it is

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

> Am 19.05.2024 um 01:12 schrieb 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

[to-be-committed][RISC-V] Eliminate redundant bitmanip operation

perl has some internal bitmap code. One of its implementation properties is that if you ask it to set a bit, the bit is first cleared. Unfortunately this is fairly hard to see in gimple/match due to type changes in the IL. But it is easy to see in the code we get from combine. So we just

Re: [PATCH v4] DSE: Fix ICE after allow vector type in get_stored_val

On 5/2/24 7:51 PM, pan2...@intel.com wrote: From: Pan Li We allowed vector type for get_stored_val when read is less than or equal to store in previous. Unfortunately, the valididate_subreg treats the vector type's size is less than vector register as invalid. Then we will have ICE here.

[pushed] wwwdocs: gcc-14: Fix seven typos

Pushed. Gerald --- htdocs/gcc-14/changes.html | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index dd3fea8d..6447898e 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -31,7

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

On 5/19/24 3:40 AM, Eric Botcazou wrote: Hi, 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

[pshed] testsuite, C++, Darwin: Skip cxa_atexit-6, which is not applicable.

As per the analysis in the PR, tested on x86_64, i686 and aarch64 Darwin (and on x86_64 linux), pushed to trunk, thanks, Iain --- 8< --- For Darwin, non-weak functions defined in a TU always bind locally and so cxa_atexit-6.C is not applicable here. PR testsuite/114982

[pushed] testsuite, darwin: Compile a test without unwind frames.

Tested on i686, x86_64 Darwin, pushed to trunk, thanks Iain --- 8< --- In the current Darwin implementation, we do not use .cfi_ insns and emitted EH frames contain 'coalesced' section designations which interfere with the scan asm. gcc/testsuite/ChangeLog: *

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

Thanks for quick response, ! Pan -Original Message- From: Eric Botcazou Sent: Sunday, May 19, 2024 5:40 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Robin Dapp ; Jeff Law Subject: Re: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR

Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

Hi Tobias, > OK for mainline? Seems reasonable, OK to push in 48 hours unless someone has suggestions related to wording. FX

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

First version was flawed, as it used the wrong type. Here is another iteration. 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

Re: [Patch] Fortran: Fix SHAPE for zero-size arrays

Hi Tobias, > That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, > caused when switching from a libgomp call to inline code and missing the > corner case of zero-size arrays … OK to push, thanks. FX

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

Hi, > 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. Sorry for the

Re: [PATCH 0/3] c++: expr-cast - C-style cast conformance [PR77465]

I noticed this patchset did not see any comment, did not get committed, and the PR is still open, so let me loop in Jason and Nathan as C++ maintainers. Ed, looking at the ChangeLog something seems missing: gcc/cp/ChangeLog: * call.c (tourney): (joust):

Re: [PATCH] added myself to maintainers

I don't see it in the tree/ChangeLog/... ? Gerald On Fri, 19 Aug 2022, Ondrej Kubanek via Gcc-patches wrote: > +2022-08-18 Ondrej Kubanek > + > + * MAINTAINERS: add myself. > + > 2022-07-04 Martin Liska > > * MAINTAINERS: fix sorting of names > diff --git a/MAINTAINERS

[Patch] Fortran: Fix SHAPE for zero-size arrays

That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, caused when switching from a libgomp call to inline code and missing the corner case of zero-size arrays ... OK for mainline + all affected branches? Tobias Fortran: Fix SHAPE for zero-size arrays PR fortran/115150

[Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

I noticed that gfortran's coarray support did not link to the http://www.opencoarrays.org/ As that library is needed to support parallelization, it makes sense to have the link. Motivated by someone claiming at ISC-HPC that GCC only supports a single image. And also motivated by Damian's

[Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic

I noticed that the last bump happened on Thursday. * * * The error is according to https://gcc.gnu.org/pipermail/gccadmin/2024q2/021298.html 2024-05-19 00:17:28,643:INFO:root:cannot find a ChangeLog location in message That's the commit --- Revert "Revert: "Enable prange

[PATCH v1 2/2] RISC-V: Add test cases for __builtin_add_overflow branchless unsigned SAT_ADD

From: Pan Li After we support branchless __builtin_add_overflow unsigned SAT_ADD from the middle end. Add more tests case to cover the functionarlities. The below test suites are passed. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/sat_arith.h: Add

[PATCH v1 1/2] Match: Support __builtin_add_overflow for branchless unsigned SAT_ADD

From: Pan Li This patch would like to support the branchless form for unsigned SAT_ADD when leverage __builtin_add_overflow. For example as below: uint64_t sat_add_u(uint64_t x, uint64_t y) { uint64_t ret; uint64_t overflow = __builtin_add_overflow (x, y, ); return (T)(-overflow) | ret;