On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
>
>
>
> Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >
> > This patch tweaks RTL expansion of multi-word shifts and rotates to use
> > PLUS rather than IOR for disjunctive operations. During expansion of
> > these operations, the middle-end c
OK I guess change register_operand into REG_P should fix those ICEs.
I will have a try and send a patch.
Thanks.
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2024-01-22 15:14
To: juzhe.zh...@rivai.ai
CC: gcc-patches; Kito.cheng; kito.cheng; jeffreyalaw; vineetg; Robin Dapp;
palmer; Patri
On Fri, Jan 19, 2024 at 9:08 PM Tobias Burnus wrote:
>
> This patch fixes PR111966, i.e. when compiling offloaded code with "-g"
> but without "-march=", mkoffload created a file with e_flags set to
> gfx803/fiji as architecture - while all other files used gfx900, which
> the linker did not like.
On Fri, Jan 19, 2024 at 5:26 PM Qing Zhao wrote:
>
>
>
> > On Jan 19, 2024, at 4:30 AM, Richard Biener
> > wrote:
> >
> > On Thu, Jan 18, 2024 at 3:46 PM Qing Zhao wrote:
> >>
> >>
> >>
> >>> On Jan 17, 2024, at 1:43 AM, Richard Biener
> >>> wrote:
> >>>
> >>> On Wed, Jan 17, 2024 at 7:42 AM
On Sun, Jan 21, 2024 at 2:33 PM Hans-Peter Nilsson wrote:
>
> Tested x86_64-linux-gnu. Ok to commit?
>
> Or, does the message need more tweaking?
> (If so, suggestions from native speakers?)
> FWIW, I found no PR for just the message being bad.
>
> -- >8 --
> When you're not regularly exposed to
在 2024/1/19 下午4:51, chenglulu 写道:
在 2024/1/19 下午1:46, Xi Ruoyao 写道:
On Wed, 2024-01-17 at 17:57 +0800, chenglulu wrote:
Virtual register 1479 will be used in insn 2744, but register 1479
was
assigned the REG_UNUSED attribute in the previous instruction.
The attached file is the wrong file.
On Sun, Jan 21, 2024 at 11:06 PM juzhe.zh...@rivai.ai
wrote:
>
> Hi, this patch causes these regressions (all ICEs) in RISC-V backend:
Note this is related to the fix for PR 109092.
But right now register_operand still accepts `(SUBREG (MEM...))`
before reload ...
So basically there is a check a
Hi, this patch causes these regressions (all ICEs) in RISC-V backend:
FAIL: gcc.dg/torture/float32-tg-2.c -O1 (internal compiler error: in
reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 (internal
Committed, thanks
xu...@eswincomputing.com
From: juzhe.zh...@rivai.ai
Date: 2024-01-22 14:40
To: Li Xu; gcc-patches
CC: kito.cheng; palmer; Li Xu
Subject: Re: [PATCH v2] RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]
LGTM.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2024-01-22 12:11
T
Notice there is a AI benchmark, GCC vs Clang has 3% performance drop.
It's because Clang/LLVM has a simplification transform vmv.v.x (avl = 1) into
vmv.s.x.
Since vmv.s.x has more flexible vsetvl demand than vmv.v.x that can allow us to
have
better chances to fuse vsetvl.
Consider this followi
LGTM.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2024-01-22 12:11
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; xuli
Subject: [PATCH v2] RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]
From: xuli
v2:
Avoid internal ICE for the case below.
vint8mf8_t test_vle8_v_i8mf8_m(vbool64_t
Thanks, nice result, I'll try to run the performance benchmarks that are
coming with libstdc++ to see if they spot anything.
That's tests in testsuite/performance folder in case you want to have a
try yourself.
François
On 18/01/2024 10:26, Huanghui Nie wrote:
Yes, I have. I did a benchma
Since the match.pd transforms (zero_one == 0) ? y : z y,
into ((typeof(y))zero_one * z) y. Add splitters to recongize
this expression to generate SFB instructions.
gcc/ChangeLog:
PR target/113095
* config/riscv/sfb.md: New splitters to rewrite single bit
sign extension as
From: xuli
v2:
Avoid internal ICE for the case below.
vint8mf8_t test_vle8_v_i8mf8_m(vbool64_t vm, const int32_t *rs1, size_t vl) {
return __riscv_vle8(vm, rs1, vl);
}
v1:
Change the hash value of overloaded intrinsic from considering
all parameter types to:
1. Encoding vector data type
2. In
On Sat, Jan 20, 2024 at 10:30 PM H.J. Lu wrote:
>
> When an interrupt handler is implemented by an assembly stub which does:
>
> 1. Save all registers.
> 2. Call a C function.
> 3. Restore all registers.
> 4. Return from interrupt.
>
> it is completely unnecessary to save and restore any registers
LGTM :)
On Mon, Jan 22, 2024 at 10:49 AM Juzhe-Zhong wrote:
>
> vfirst/vmsbf/vmsif/vmsof instructions are supposed to demand ratio instead of
> demanding sew_lmul.
> But my previous typo makes VSETVL PASS miss honor the risc-v v spec.
>
> Consider this following simple case:
>
> int foo4 (void *
vfirst/vmsbf/vmsif/vmsof instructions are supposed to demand ratio instead of
demanding sew_lmul.
But my previous typo makes VSETVL PASS miss honor the risc-v v spec.
Consider this following simple case:
int foo4 (void * in, void * out)
{
vint32m1_t v = __riscv_vle32_v_i32m1 (in, 4);
v = __r
Hi all,
Recently, I happened to run i386.exp under -DDEBUG and found some fail.
This patch aims to fix that. Ok for trunk?
Thx,
Haochen
gcc/testsuite/ChangeLog:
* gcc.target/i386/adx-check.h: Include stdio.h when DEBUG
is defined.
* gcc.target/i386/avx512fp16-vscalefph-
On Sun, 2024-01-21 at 19:14 -0700, Jeff Law wrote:
> The change for pr111267 twiddled code generation for sh/pr59533-1.c
>
> We end up eliminating two comparisons, but require two shll instructions
> to do so. And in a couple places we're using an addc sequence rather
> than a subc sequence.
On 1/15/24 06:34, Richard Biener wrote:
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
src_ptr + (d
The change for pr111267 twiddled code generation for sh/pr59533-1.c
We end up eliminating two comparisons, but require two shll instructions
to do so. And in a couple places we're using an addc sequence rather
than a subc sequence. This patch adjusts the expected codegen for the
test as all
On Jan 21 2024, Jeff Law wrote:
> Yea. The biggest problem with ATTRIBUTE_UNUSED is that it's a "may be
> unused" and thus if the code changes it's sometimes left on an parameter
> incorrectly. C++ allows us to specify a "is definitely unused" concept by
> dropping the parameter's name, but leav
On 1/16/24 10:13, Mary Bennett wrote:
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-alu-fail-compile.c: Change warning to error.
AFAICT this is independent of the other patches and fixes a clear
testsuite issue. I've pushed it to the trunk.
Thanks,
Jeff
On 1/16/24 09:25, Mary Bennett wrote:
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Hel
On 1/16/24 09:55, Mikael Pettersson wrote:
On Thu, 4 Jan 2024 14:39:23 -0700, Jeff Law wrote:
On 1/4/24 02:23, Mikael Pettersson wrote:
emit_library_call_value_1 calls emit_push_insn with NULL_TREE
for TYPE. Sometimes emit_push_insn needs to assign a temp with
that TYPE, which causes a segf
On 1/17/24 11:21, Martin Jambor wrote:
Hi,
PR 110422 shows that SRA can ICE assuming there is a single edge
outgoing from a block terminated with an asm goto. We need that for
BB-terminating statements so that any adjustments they make to the
aggregates can be copied over to their replacemen
On 1/19/24 18:18, 钟居哲 wrote:
OK. I saw the other arguments there:
tree fntype ATTRIBUTE_UNUSED,
rtx libname ATTRIBUTE_UNUSED,
So I leverage these and add ATTRIBUTE_UNUSED to 'fndecl'
Maybe it's better remove all arguments for riscv_i
The signature was still using ATTRIBUTE_UNUSED and actually marked one
of the used arguments with ATTRIBUTE_UNUSED.
This patch drops the decorations and instead remove the name of
arguments which are actually unused which is the preferred way to handle
this now when we can.
Bootstrapped.
Tested aarch64-linux. Pushed to trunk.
Backport to gcc-13 would be good too, I think.
-- >8 --
Currently trying to use std::format with certain specializations of
std::chrono::time_point is ill-formed, due to one member function of the
__formatter_chrono type which tries to write a time_point to
Tested aarch64-linux. Pushed to trunk. Backport needed to gcc-13 too.
-- >8 --
THe std::chrono::file_clock conversions were not using common_type and
so failed to compile when converting anything that should have increased
precision after arithmetic with a std::chrono::seconds value.
libstdc++-v
Am 20.01.24 um 23:42 schrieb Alexander Westbrooks:
Based on what I am reading here, I can either do the DCO path or the copy
right form path? Or is it both, where I send in the copy right forms and
then on every commit I put the DCO?
I thought the text is pretty clear. As already mentioned,
gcc/ChangeLog
PR c++/90464
* doc/invoke.texi (Warning Options): Document that -Wunused-parameter
isn't enabled by -Wunused unless -Wextra is provided, and that
-Wunused does enable -Wunused-const-variable=1 for C. Clarify that
-Wunused doesn't enable -Wunuse
Hi Mikael!
Am 21.01.24 um 11:50 schrieb Mikael Morin:
Hello,
Le 20/01/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
here's the first part of an attempt to fix issues with optional
dummy arguments as actual arguments to optional dummies. This patch
rectifies the case of scalar dummies with
On Thu, Jan 18, 2024 at 3:37 PM Tom Tromey wrote:
>
> Andrew> This change is causing some problems for me.
>
> Yeah, Tom de Vries as well.
>
> Andrew> One of my build machines has 2 versions of guile installed. One is
> Andrew> guile 2.0.14 and the other is guile 2.2.21.
>
> Andrew> When GDB conf
Hello All:
New pass to replace adjacent memory addresses lxv with lxvp.
Added common infrastructure for load store fusion for
different targets.
Common routines are refactored in fusion-common.h.
AARCH64 load/store fusion pass is not changed with the
common infrastructure.
For AARCH64 archit
Hello All:
New pass to replace adjacent memory addresses lxv with lxvp.
Added common infrastructure for load store fusion for
different targets.
Common routines are refactored in fusion-common.h.
AARCH64 load/store fusion pass is not changed with the
common infrastructure.
For AARCH64 archit
Tested aarch64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
The logic for handling '#' forms was ... not good. The count of
significant figures just counted digits, instead of ignoring leading
zeros. And when moving the result from the stack buffer to a dynamic
string the expone
Tested x86_64-linux-gnu. Ok to commit?
Or, does the message need more tweaking?
(If so, suggestions from native speakers?)
FWIW, I found no PR for just the message being bad.
-- >8 --
When you're not regularly exposed to this warning, it is
easy to be misled by its wording, believing that there'
Hello,
Le 20/01/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
here's the first part of an attempt to fix issues with optional
dummy arguments as actual arguments to optional dummies. This patch
rectifies the case of scalar dummies with the VALUE attribute,
which in gfortran's argument passin
39 matches
Mail list logo
