After two months on trunk, this has been backported:
Fortran: Fix some problems blocking associate meta-bug [PR87477]
2023-08-27 Paul Thomas
gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expr
The pressure sensitive scheduling change perturbs the output ever so
slightly for this test. Seemed easiest to just turn that off rather
than generalize the expected output enough to work across all the
relevant optimization options.
Pushed to the trunk.
Jeff
commit b3b13fb1cbad6e5836dee94
Jivan's recent work on IRA results in more efficient code for this test.
This adjusts the expected output for the removal of 5 instructions and
conversion of an addi into a simple mv.
Pushed to the trunk,
Jeffcommit 6567837fd823a93f7f7948a73ff9dc1153592e8c
Author: Jeff Law
Date: Sun Aug 27
Jivan's work also results in using a different save/restore function for
the spill-11 test. So the expected output needs minor adjusting.
Committed to the trunk.
Jeff
commit 3745feb19ed072e0865b12a891d7dbf7ba12c337
Author: Jeff Law
Date: Sun Aug 27 13:00:13 2023 -0600
RISC-V: Fix spi
Hello,
this fixes an old error-recovery bug.
Tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Keep memory of the content of the current interface body being parsed
and restore it to its previous state if it has been modified at the time
a parse attempt fails.
This fixes memory errors and
This adds a simple case to remove an outer condition if the two inner
condtionals are the same and lead the same location.
This can show up due to jump threading or inlining or someone wrote code
like this.
ifcombine-1.c shows the simple case where this is supposed to solve.
Even though PRE can ha
Thanks kito.
Address all comments and committed with V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628423.html
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-08-25 01:01
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH V2] RISC-V: Refactor
Committed.
Fix failures:
FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-10.c -O2
scan-assembler-times
add\\ta[0-7],a[0-7],a[0-7]\\s+\\.L[0-9][0-9][0-9]\\:\\s+vle32\\.v\\s+(?:v[0-9]|v[1-2][0-9]|v3[0-1]),0\\s*\\([a-x0-9]+\\)
1
FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-10.c -O2
sca
on 2023/8/26 06:04, Peter Bergner wrote:
> On 8/25/23 6:20 AM, Kewen.Lin wrote:
>> Assuming the current PCREL_SUPPORTED_BY_OS unchanged, when
>> PCREL_SUPPORTED_BY_OS is true, all its required conditions are
>> satisfied, it should be safe. while PCREL_SUPPORTED_BY_OS is
>> false, it means the giv
Hi Carl,
on 2023/8/25 03:53, Carl Love wrote:
> GCC maintainers:
>
> Version 3, fixed the built-in instance names. Missed removing the "n"
> the name. Added the tighter constraints on the predicates for the
> define_insn. Updated the wording for the built-ins in the
> documentation file. Chan
Hi, Jeff,
Ping this patch since 18 days have passed. Is there any problem with
this patch after the last discussion? This is a bugfix patch, it will
affect the correctness, hope to have another look, thank you very much.
There seems to be a major question at the moment as to why I add a
forc
Ok.
I am not familiar with scheduling stuff but I hope you can fix those 2 issues.
I have no objection with this patch and I prefer Jeff or kito make the decision
for this patch.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-23 22:56
To: 钟居哲; gcc-patches; palmer; kito.cheng; J
This patch should be backported to releases/gcc-13 to address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111076
--
Li Xu
>This issue happens is because the operand1 of scalar move can be
>REG_P (operand[1]) in the O0 case, which causes the VSETVL PASS to
>not insert the vsetvl instr
Thanks for taking care of this issue.
Ok to backport GCC-13.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-08-28 10:33
To: xuli1; gcc-patches
CC: kito.cheng; palmer; juzhe.zhong
Subject: Re: [PATCH V2] RISC-V: Insert vsetivli zero, 0 for vmv.x.s/vfmv.f.s
instructions satisfying REG_P(operand[1]
Pushed to r14-3511.
在 2023/8/25 下午5:31, Lulu Cheng 写道:
v1 -> v2:
1. Modify description information
Since the SLT instruction does not distinguish between 64-bit operations and
32-bit
operations under the 64-bit LoongArch architecture, if the operand of slt is
SImode,
the sign extensi
Hi,
For PowerPC, some INT mode and FLOAT modes can be marked as tieable,
for example: DI<->DF.
One note SFmode is special, it would only tieable with itself.
I updated previous patch more reasonable:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html
Bootstrap and regtest pass on
Hi, this patch is enabling vec_init for RVV VLA vectorization since we have
almost
support all RVV-related features to the middle-end loop vectorizer.
Test report:
FAIL: gcc.dg/vect/bb-slp-10.c -flto -ffat-lto-objects scan-tree-dump slp2
"unsupported unaligned access"
FAIL: gcc.dg/vect/bb-slp-1
gcc/ChangeLog:
* common/config/loongarch/loongarch-common.cc:
Enable '-free' on O2 and above.
* doc/invoke.texi:
Modify the description information of the '-free'
compilation option and add the LoongArch description.
gcc/testsuite/ChangeLog:
* gcc.
v1 -> v2:
1. Modify Changelog information format.
gcc/ChangeLog:
* common/config/loongarch/loongarch-common.cc:
Enable '-free' on O2 and above.
* doc/invoke.texi: Modify the description information
of the '-free' compilation option and add the LoongArch
> @@ -11100,6 +11101,15 @@ proc check_vect_support_and_set_flags { } {
> }
> } elseif [istarget amdgcn-*-*] {
> set dg-do-what-default run
> +} elseif [istarget riscv64-*-*] {
> + if [check_effective_target_riscv_vector_hw] {
> + lappend DEFAULT_VECTCFLAGS
After r14-2885-gb9237226fdc938, this pattern becomes
redundant as we match it using bitwise_inverted_equal_p.
There is already a testcase (gcc.dg/nand.c) for this pattern
and it still passes after the removal.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
LTGT_EXPR hasn't been handling relations, especially with NANs as a
possibility. This handles them while documenting how relations work
in a world with NANs.
Basically we need to special case VREL_EQ before calling
frelop_early_resolve. Note that VREL_EQ on entry to a range-op entry
is really VR
22 matches
Mail list logo