On Sun, 23 Jul 2023, Lehua Ding wrote:
> Hi Richard,
>
>
> Bootstrap and regression are passed on X86 and
> no new testcases fail on AArch64 with V5 patch:
>
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625293.html
>
>
> V5 patch is ok for trunk?
Yes.
on 2023/7/21 19:49, Richard Biener wrote:
> On Fri, Jul 21, 2023 at 8:08 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> The function vect_update_epilogue_niters which has been
>> removed by r14-2281 has some code taking care of that if
>> there is only one scalar iteration left for epilogue then
>> we won't
Hi Martin,
Not sure about your current option about re-using the ipa-sra code
in the light-expander-sra. And if anything I could input please
let me know.
And I'm thinking about the difference between the expander-sra, ipa-sra
and tree-sra. 1. For stmts walking, expander-sra has special behavio
Hi,
A couple of virtual functions in the libstdc++ format header are marked
constexpr in the base class, but not in the derived class. This was causing
build failures when trying to compile latest gcc libstd with clang 16 using
c++20. Adding the constexpr specifier resolves the issue.
2023-07-23
Passed the riscv.exp/rvv.exp in both rv32 and rv64 in PATCH v6 as below.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625315.html
Pan
From: Li, Pan2
Sent: Monday, July 24, 2023 9:52 AM
To: 'juzhe.zh...@rivai.ai' ; gcc-patches
Cc: Kito.cheng ; Wang, Yanzhang
Subject: RE: [PATCH v5] RISC
Hi Haochen,
on 2023/7/21 09:32, HAO CHEN GUI wrote:
> Hi,
> This patch modifies vsx extract expand and generates mfvsrwz/stxsiwx
> for all subtargets when the mode is V4SI and the index of extracted element
> is 1 for BE and 2 for LE. Also this patch adds a insn pattern for mfvsrwz
> which can h
From: Pan Li
In basic dynamic rounding mode, we simply ignore call instructions and
we would like to take care of call in this PATCH.
During the call, the frm may be updated or keep as is. Thus, we must
make sure at least 2 things.
1. The static frm before call should not pollute the frm value
Hi Carl,
on 2023/7/22 07:38, Carl Love wrote:
> GCC maintainers:
>
> Version 5, Fixed patch description, the first argument should be of
> type vector. Fixed comment in vsx.md to say "Vector and scalar
> extract_elt iterator/attr ". Removed a few of the changes in
> version 4. Specifically
Hi Richard,
Gentle ping. Is it ok for trunk?
Or, you will have patch covering such fix?
Thanks,
-Hao
From: Hao Liu OS
Sent: Wednesday, July 19, 2023 12:33
To: GCC-patches@gcc.gnu.org
Cc: richard.sandif...@arm.com
Subject: [PATCH] AArch64: Do not increa
Hi Carl,
on 2023/7/22 07:38, Carl Love wrote:
> GCC maintainers:
>
> Version 2: Updated a number of formatting and spacing issues. Added
> the NARGS description to the header comment for function find_instance.
> This patch was tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
> with no r
Hi Iain,
on 2023/7/22 23:58, Iain Sandoe wrote:
> Hi Kewen,
>
> This patch breaks bootstrap on powerpc-darwin (which has Altivec, but not
> VSX) while building libgfortran.
>
>> On 3 Jul 2023, at 04:19, Kewen.Lin via Gcc-patches
>> wrote:
>
> Please see https://gcc.gnu.org/bugzilla/show_bug.
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Monday, July 24, 2023 8:53 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Bugfix for allowing incorrect dyn for static
rounding
Ok. You can commit it.
___
Overall LGTM from my side.
But we should wait for Kito's review.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-23 21:11
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v5] RISC-V: Support CALL for RVV floating-point dynamic rounding
From: Pan Li
In b
Ok. You can commit it.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-23 21:54
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfix for allowing incorrect dyn for static
rounding
From: Pan Li
According to the spec, dyn rounding mode is in
On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote:
> It occurs to me that the model I am envisioning is similar to CMake's object
> libraries. Object libraries are a convenient name for a bunch of object
> files.
> IIUC they're linked by naming the individual object files (or I think
On Linux/x86_64,
65ff4a45b11b5ab13ef849bd5721ab28ff316202 is the first bad commit
commit 65ff4a45b11b5ab13ef849bd5721ab28ff316202
Author: Jan Hubicka
Date: Fri Jul 21 14:54:23 2023 +0200
loop-ch improvements, part 5
caused
FAIL: gcc.target/i386/pr93089-2.c scan-assembler vmulps[^\n\r]*zm
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
In the Fortran front end, most of the
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C++ front end
In order to detect invalid jumps in and out of intervening code in
imperfectly-nested loops, the front ends need to insert some sort of
marker to identify the structured block sequences that they push into
the inner body of the loop. The error checking happens in the
diagnose_omp_blocks pass, betw
gcc/testsuite/ChangeLog
* c-c++-common/gomp/imperfect-attributes.c: New.
* c-c++-common/gomp/imperfect-badloops.c: New.
* c-c++-common/gomp/imperfect-blocks.c: New.
* c-c++-common/gomp/imperfect-extension.c: New.
* c-c++-common/gomp/imperfect-gotos.c: New.
Here is the latest version of my imperfectly-nested loops patches.
Compared to the initial version I'd posted in April
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617103.html
this version includes many minor cosmetic fixes suggested by Jakub in
his initial review (also present in the ver
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C front end to
From: Pan Li
According to the spec, dyn rounding mode is invalid for RVV
floating-point, this patch would like to fix this.
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-shapes.cc
(struct alu_frm_def): Take range check.
gcc/testsuite/ChangeLog:
From: Pan Li
In basic dynamic rounding mode, we simply ignore call instructions and
we would like to take care of call in this PATCH.
During the call, the frm may be updated or keep as is. Thus, we must
make sure at least 2 things.
1. The static frm before call should not pollute the frm value
On Linux/x86_64,
92d1425ca7804000cfe8aa635cf363a87d362d75 is the first bad commit
commit 92d1425ca7804000cfe8aa635cf363a87d362d75
Author: Patrick Palka
Date: Wed Jul 19 16:10:20 2023 -0400
c++: redundant targ coercion for var/alias tmpls
caused
FAIL: g++.dg/gomp/pr58567.C -std=c++14 (te
> Am 23.07.2023 um 01:27 schrieb Andrew Pinski via Gcc-patches
> :
>
> This adds a special case of the `(a&~b) | b` pattern where
> `b` and `~b` are comparisons.
>
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Don’t we have an existing match for inversion s we could
26 matches
Mail list logo