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
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]
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #9 from Jiang An ---
See also CWG2753.
https://cplusplus.github.io/CWG/issues/2753.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104095
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #2 from
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.
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
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
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.cgi?id=110776
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110786
Jose E. Marchesi changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110785
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110786
Bug ID: 110786
Summary: bpf: make use of the V4 byte swap instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110785
Bug ID: 110785
Summary: Incorrect return type deduction for const auto with no
return statement
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110784
Bug ID: 110784
Summary: bpf: make use of the V4 sign-extended move
instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110783
Bug ID: 110783
Summary: bpf; make sure of V4 signed division/modulus
instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110782
Bug ID: 110782
Summary: bpf: make use of the V4 sign-extended load
instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110781
Bug ID: 110781
Summary: bpf: make use of the V4 long-range jump instruction
(jal/gotol)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Snapshot gcc-14-20230723 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20230723/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
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
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,
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110780
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|target
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Compile the following with gcc 14.0.0 20230723 on aarch64 with -O3:
#include
void CSI2toBE12(uint8_t* pCSI2, uint8_t* pBE, uint8_t* pCSI2LineEnd)
{
while (pCSI2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-07-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Bug ID: 110779
Summary: SysClock can not read the clock
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98433
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72825
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699
Andrew Pinski changed:
What|Removed |Added
Target Milestone|12.4|14.0
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72825
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109598
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110750
--- Comment #1 from Thomas Schwinge ---
... but it *does not* FAIL in my powerpc64le testing with Nvidia Tesla V100
(but *does* FAIL with powerpc64le Nvidia Quadro GV100 in the same way as it
does for x86_64 originally reported here).
> 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
On Jul 22 2023, Andrew Pinski via Gcc-patches wrote:
> The problem -fasynchronous-unwind-tables is on by default for riscv linux
> We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
> to .eh_frame data from crtbeginT.o instead of the user-defined object
> during static
49 matches
Mail list logo
