The following committed patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
The patch was successfully bootstrapped and tested on x86-64.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d63b83194d5..4ea81e6c404 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
On 2020-03-30 12:06 p.m., David Malcolm wrote:
It's a double-free bug in lra.c, albeit one that requires being used
in a multithreaded way from libgccjit to be triggered.
libgccjit's test-threads.c repeatedly compiles and runs numerous tests,
each in a separate thread.
Attempting to add an
On 2020-03-20 1:19 p.m., Richard Sandiford wrote:
Ping
Richard, sorry. I missed your original message.
Richard Sandiford writes:
[See:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541694.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541759.html
for a
The following committed patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
The patch was successfully bootstrapped and tested on x86-64.
The following patch improves hard reg pref cost propagation in IRA.
Hard reg preferences are created mainly from moves involving hard regs
in RTL.
The patch does the propagation during coloring now and also updates
conflict costs which affects hard reg preferences for conflicting
Richard, thank you for working on this issue and for as usually detailed
explanation of the problem.
On 2020-08-28 9:52 a.m., Richard Sandiford wrote:
...
The patch is quite aggressive in that it does this for all reload
pseudos in all reload instructions. I wondered about reusing the
On 2020-10-14 10:21 a.m., Martin Liška wrote:
Hello.
There's a new version of the patch that fixes profile scaling
in IRA.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Yes. Thank you, Martin.
On 2020-10-11 8:58 p.m., Hongtao Liu wrote:
Hi:
This is done in 2 steps:
1. Extend special memory constraint to handle non MEM_P cases, i.e.
(vec_duplicate:V4SF (mem:SF (addr)))
2. Refactor implementation of *_bcst{_1,_2,_3} patterns. Add new
predicate bcst_mem_operand and
On 2020-10-20 1:33 a.m., Hongtao Liu wrote:
On Mon, Oct 19, 2020 at 11:38 PM Vladimir Makarov wrote:
On 2020-10-11 8:58 p.m., Hongtao Liu wrote:
Hi:
This is done in 2 steps:
1. Extend special memory constraint to handle non MEM_P cases, i.e.
(vec_duplicate:V4SF (mem:SF (addr)))
The following patch has been committed into the main line. The patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
The patch was successfully bootstrapped and tested on x86-64.
gcc/ChangeLog:
2020-10-09 Vladimir Makarov
PR rtl-optimization/97313
* lra-constraints.c
On 2020-08-25 6:18 a.m., Alex Coplan wrote:
The motivation here is to be able to remove several redundant patterns
in the AArch64 backend. See the previous thread [1] for context.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu.
* New unit test
On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
Alex Coplan writes:
Minor nit, should be formatted as:
static rtx
canonicalize_reload_addr (rtx addr)
Sorry for missing this. Alex, it should be fixed anyway.
I don't think we should we restrict this to (plus (mult X Y) Z),
since
On 2020-08-26 11:15 a.m., Alex Coplan wrote:
Thanks for the review, both.
Please find a reworked version of the patch attached incorporating
Richard's feedback.
Testing:
* Bootstrap and regtest on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, and x86_64-pc-linux-gnu: no regressions.
On 2020-09-29 8:38 a.m., H.J. Lu wrote:
On Fri, Sep 25, 2020 at 6:46 AM H.J. Lu wrote:
OK for GCC 10 branch?
Thanks.
PING:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554268.html
PING.
PING.
Sorry, I thought Jeff Law already approved this. In any case the patch
is also
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
The patch was successfully bootstrapped and tested on x86-64. I did not
test it on other major targets as they do not deal with STRICT_LOW_PART.
There is also no test case for this PR as it is hard to
On 2020-06-04 12:55 p.m., H.J. Lu wrote:
On Thu, Jun 4, 2020 at 9:17 AM Jakub Jelinek via Gcc-patches
wrote:
The testcase from the PR was a dg-do run testcase that FAILed without your
patch, can't we just use that testcase (in gcc.target/i386/, restricted to
lp64 and possibly linux only to
I've added the testcase for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
diff --git a/gcc/testsuite/gcc.target/i386/pr95464.c b/gcc/testsuite/gcc.target/i386/pr95464.c
new file mode 100644
index 000..33a8290e0cf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr95464.c
@@ -0,0
On 2020-06-04 12:17 p.m., Jakub Jelinek wrote:
On Thu, Jun 04, 2020 at 12:13:51PM -0400, Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
The patch was successfully bootstrapped and tested on x86-64. I did
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
The patch was successfully bootstrapped on x86-64.
[PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)` after elimination
LRA can loop infinitely on targets without `reg + imm` insns. Register
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
commit fbf9b2b634e376516cd21d7aa92ef3fd5778aa10 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Jan 6 14:48:53 2021 -0500
[PR97978] LRA: Permit temporary
On 2021-01-07 6:01 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
Can you explain this a bit more? The assert fires if the register
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
The patch was successfully bootstrapped on x86_64 and s390x (with
--enable-languages=c,c++ --enable-checking=release --disable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
The patch was successfully bootstrapped on x86-64 and s390x.
commit fb352136db34a7adbc7be6a1e4e90b56bc632ebd (HEAD -> master)
Author: Vladimir N. Makarov
Date: Tue Nov 24 11:25:16 2020 -0500
[PR97933] LRA:
On 2020-12-10 10:12 a.m., Andrea Corallo wrote:
Hi all,
following discussion on PR97092 I'd like to submit the following patch
with a fix plus associated testcase.
With this patch applied mode is recomputed at each iteration while
looping across different copies in
On 2020-12-14 11:23 a.m., Andrea Corallo wrote:
Vladimir Makarov writes:
On 2020-12-10 10:12 a.m., Andrea Corallo wrote:
Hi all,
following discussion on PR97092 I'd like to submit the following patch
with a fix plus associated testcase.
With this patch applied mode is recomputed at each
The following patch implements asm goto with outputs. Kernel
developers several times expressed wish to have this feature. Asm
goto with outputs was implemented in LLVM recently. This new feature
was presented on 2020 linux plumbers conference
The original patch has been modified according to the reviewers comments
and the following patch has been committed.
commit e3b3b59683c1e7d31a9d313dd97394abebf644be
Author: Vladimir N. Makarov
Date: Fri Nov 13 12:45:59 2020 -0500
[PATCH] Implementation of asm goto outputs
gcc/
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870
The patch was successfully bootstrapped and tested on x86-64.
[PR97870] LRA: don't remove asm goto, just nullify it.
gcc/
2020-11-18 Vladimir Makarov
PR target/97870
On 2020-11-13 4:00 a.m., Richard Biener wrote:
On Thu, Nov 12, 2020 at 8:55 PM Vladimir Makarov via Gcc-patches
wrote:
The following patch implements asm goto with outputs. Kernel
developers several times expressed wish to have this feature. Asm
goto with outputs was implemented in LLVM
On 2020-11-13 10:51 a.m., Uros Bizjak wrote:
diff --git a/gcc/testsuite/gcc.c-torture/compile/asmgoto-4.c
b/gcc/testsuite/gcc.c-torture/compile/asmgoto-4.c
new file mode 100644
index 000..8685ca2a1cb
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/asmgoto-4.c
@@ -0,0 +1,14 @@
My last patch implementing output reloads in asm goto resulted in LRA
crash in compiling kernel on s390x. Jeff Law reported it recently. The
culprit was in incorrect emitting reload insns in last empty BB. The
emitted insns got null BB which is wrong. Actually in this case we do
not need to
On 2020-10-27 2:52 a.m., Hongtao Liu wrote:
Hi:
Sorry for Incomplete test for my last patch at
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555948.html.
This patch should fix invalid address introduced by special memory
constraint.
Bootstrap is ok, regression test is ok for
After submitting the patch dealing with insn scratches in IRA, a report
came that sync-3.c started to fail with x86_64-aarch64 cross-compiler.
The following patch fixes this problem. The patch was successfully
bootstrapped on x86-64.
commit 885cbb4a0a677299de34d9e413818df5bb8272b1
Author:
On 2020-11-02 3:12 p.m., Christophe Lyon wrote:
Hi,
This patch causes ICEs on arm (eg arm-none-linux-gnueabi)
gcc.c-torture/compile/sync-3.c -O1 (internal compiler error)
gcc.c-torture/compile/sync-3.c -O2 (internal compiler error)
gcc.c-torture/compile/sync-3.c -O2
On 2020-11-02 4:30 p.m., Vladimir Makarov via Gcc-patches wrote:
On 2020-11-02 3:12 p.m., Christophe Lyon wrote:
Hi,
This patch causes ICEs on arm (eg arm-none-linux-gnueabi)
gcc.c-torture/compile/sync-3.c -O1 (internal compiler error)
gcc.c-torture/compile/sync-3.c -O2
On 2020-10-27 2:53 a.m., Hongtao Liu wrote:
Hi:
For inline asm, there could be an operand like (not (mem:)), it's
not a valid operand for normal memory constraint.
Bootstrap is ok, regression test is ok for make check
RUNTESTFLAGS="--target_board='unix{-m32,}'"
gcc/ChangeLog
PR
The following patch fixes failures for test p9-extract-2.c on
ppc64. The failures are a result of committing patch dealing with insn
scratches in IRA. The pseudo corresponding the 1st scratch in the
following insn get unexpected register class (general regs) and
unexpected insn alternative
The following patch implements taking insn scratch requirements into
account in global RA (IRA). Before the patch IRA simply ignored insn
scratches. Only LRA took the scratches into account and assigned hard
registers to scratches if neccessary. In some cases it resulted in
spilling pseudos
On 2020-10-30 7:36 p.m., Segher Boessenkool wrote:
Thanks for the patch! But it has a problem:
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 67e4f2fd037..78de85ccbbb 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -3717,7 +3717,7 @@
On 2020-11-02 6:43 a.m., Segher Boessenkool wrote:
Hi!
On Sun, Nov 01, 2020 at 06:32:02PM -0500, Vladimir Makarov wrote:
On 2020-10-30 7:36 p.m., Segher Boessenkool wrote:
Thanks for the patch! But it has a problem:
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index
On 2020-10-20 10:11 p.m., Hongtao Liu wrote:
Changed, and it passed the i386/x86-64 regression test.
Update patch.
Thank you, Hongtao. This patch is ok for the trunk.
On 2020-11-06 1:15 a.m., Kewen.Lin wrote:
Hi,
As PR97705 shows, my commit r11-4637 caused some dumping
comparison difference error on pass ira. It exposed one
issue about the newly introduced function remove_scratches,
which can increase the largest pseudo reg number if it
succeeds, later
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
The patch was successfully bootstrapped and tested on x86-64.
[PR98722] LRA: Check that target has no 3-op add insn to transform 2 plus expression.
Patch cf2ac1c30af0fa783c8d72e527904dda5d8cc330 for solving
The following patch fixes recently reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
The patch was successfully bootstrapped on x86-64.
[PR98777] LRA: Use preliminary created pseudo for in LRA elimination subpass
LRA did not extend ira_reg_equiv after generation of a pseudo in
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
[PR97847] IRA: Skip abnormal critical edge splitting
PPC64 can generate jumps with clobbered pseudo-regs and a BB with
such jump can have
On 2021-01-18 7:50 a.m., Richard Biener wrote:
On Mon, 18 Jan 2021, Przemyslaw Wirkus wrote:
Hi all,
Can we backport PR97969 patch to GCC 10 and (maybe) GCC 9 ?:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
IMHO bug is severe and could land in GCC 10 and 9. Vladimir's original patch:
commit 0202fa3d6359911a9e6d605d33d0ac669e21eaf3
Author: Vladimir N. Makarov
Date: Fri Jan 29 16:04:03 2021 -0500
[PR97701] Modify test for trunk
Original test was for gcc-10. The modified one for trunk.
gcc/testsuite/ChangeLog:
PR target/97701
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
The patch was successfully bootstrapped and tested on x86-64, arm64,
ppc64be.
This patch variant is only for trunk. GCC-10 branch will have a bit
different patch.
commit
The patch solves the following problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
The patch was successfully bootstrapped and tested on x86-64.
commit 238ea13cca75ad499f227b60a95c40174c6caf78
Author: Vladimir N. Makarov
Date: Wed Jan 27 14:53:28 2021 -0500
[PR97684] IRA:
On 2021-05-25 5:14 a.m., Przemyslaw Wirkus wrote:
Hi,
Just a follow up after GCC 11 release.
I've backported to gcc-10 branch (without any change to original patches)
PR97969 and following PR98722 & PR98777 patches.
Commits apply cleanly without changes.
Built and regression tested on:
*
On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
Hi!
on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
Hi,
PR100328 has some details about this issue, I am trying to
brief it here. In the hottest function LBM_performStreamCollideTRT
of SPEC2017 bmk 519.lbm_r, there are many FMA style
On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
Hi!
on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
Hi,
PR100328 has some details about this issue, I am trying to
brief it here. In the hottest function LBM_performStreamCollideTRT
of SPEC2017 bmk 519.lbm_r, there are many FMA style
On 2021-07-01 10:11 p.m., Kewen.Lin wrote:
Hi Vladimir,
on 2021/6/30 下午11:24, Vladimir Makarov wrote:
Many thanks for your review! I've updated the patch according to your comments
and also polished some comments and document words a bit. Does it look better
to you?
Sorry for the delay
On 2021-04-23 12:13 p.m., Richard Sandiford wrote:
This is a backport of the PR96796 fix to GCC 10 and GCC 9. The original
trunk patch was:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552878.html
reviewed here:
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
The patch is for a new GCC extension -- asm goto with output reloads.
GCC splits inout operands (with constraint "+") into output and new
matched input operands during gimplfication. Addressing input or output
It seem that my recent patch for PR97701 for the trunk did not create
new problems. Therefore I am committing the following patch into
gcc-10-branch.
commit 4918937f4c76b05eaa331f8d6f2571e2fddcc22b (HEAD -> releases/gcc-10)
Author: Vladimir N. Makarov
Date: Thu Feb 4 15:57:55 2021 -0500
On 2021-01-28 5:40 a.m., Ilya Leoshkevich via Gcc-patches wrote:
Hello,
I would like to ping the following patch:
lra: clear lra_insn_recog_data after simplifying a mem subreg
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563428.html
Sorry, I missed your original email. The patch
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
The patch was successfully bootstrapped and tested on aarch64.
commit 0d37e2d3ead072ba57e03fcb97a041504a22e721
Author: Vladimir Makarov
Date: Fri Mar 26 17:09:24 2021 +
[PR99766] Consider relaxed memory
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit 1458059fc1faf6170f2fe45159065f91876307ac
Author: Vladimir N. Makarov
Date: Wed Mar 31 13:26:30 2021 -0400
On 2021-03-23 9:07 a.m., Christophe Lyon wrote:
On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
wrote:
Hi,
This patch causes regressions (116) on aarch64:
gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c -std=gnu90 -O2
On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.
Can you check this too and if I am doing something
On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov
wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.
On 2021-03-23 5:33 p.m., Richard Sandiford wrote:
Vladimir Makarov writes:
On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
Here is the patch solving the problem.
Also although asm tests only checks assembler code, a lot of them use
dg-require-effective-target and therefore can not be
This is an additional patch for PR99422:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit a4670f58ebff805e35268542aac35f9791980954
Author: Vladimir N. Makarov
Date: Thu Mar 18 15:58:26 2021 -0400
On 2021-03-10 5:25 a.m., Andre Vieira (lists) wrote:
On 19/02/2021 15:05, Vladimir Makarov wrote:
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
On 2021-03-09 9:26 a.m., Jakub Jelinek wrote:
On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches
wrote:
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 76e3ff7efe6..feff766c590 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3452,6
On 2021-03-09 9:53 a.m., Martin Liška wrote:
On 3/9/21 3:12 PM, Vladimir Makarov via Gcc-patches wrote:
The patch was successfully bootstrapped and tested on x86-64,
ppc64le, and arm64. Unfortunately, I did not manage to reduce the
test (whose size is 5MB).
I've just reduced test-case
Here is the patch taking all the proposals into account.
Successfully bootstrapped on x86-64.
commit 7ad6b73421e3599628bf52fb175f004ce13f2ae9 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Tue Mar 9 10:57:21 2021 -0500
[PR99454] LRA: Process separately 'g' and digital constraints >
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and arm64. Unfortunately, I did not manage to reduce the test (whose
size is 5MB).
commit 9725df0233b6fb6e761875968b3b8e9fd9f522ac (HEAD ->
Here is one more patch for PR99422. The patch was successfully tested
and bootstrapped on x86-64.
commit e647130d441887657cf0e1c2c3b40ab1ca9beb47 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Mar 10 16:15:08 2021 -0500
[PR99422] LRA: Don't check unknown constraint, use X for
On 2021-03-19 11:03 a.m., Alex Coplan wrote:
Hi Vladimir,
On 19/03/2021 10:21, Vladimir Makarov via Gcc-patches wrote:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully tested and bootstrapped on x86-64, ppc64le
On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully tested and bootstrapped on x86-64, ppc64le,
aarch64.
Is it ok for the trunk
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully tested and bootstrapped on x86-64, ppc64le,
aarch64.
Is it ok for the trunk?
commit 20a38c39e57fe4d8a72391184e3b67129f0bf88c
Author: Vladimir N. Makarov
Date: Fri Mar
On 2021-03-22 6:22 a.m., Richard Sandiford wrote:
'\0' is just a normal string null terminator and so I don't think we
should be processing it as if it were a constraint character.
How about having a gcc_unreachable on zero instead?
I would be nice to use gcc_unreachable but it requires to
On 2021-03-21 8:51 a.m., Richard Sandiford wrote:
Vladimir Makarov writes:
On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99663
The patch was successfully bootstrapped and tested on x86-64.
commit d81019db099ad95febbb2d4b4afd8cbe95762062
Author: Vladimir N. Makarov
Date: Fri Mar 19 15:34:48 2021 -0400
[PR99663] Don't use unknown
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680
The patch was successfully bootstrapped on x86-64.
commit c1ab0c0336d85f5e97739060ecf77fd05ac86d2a
Author: Vladimir N. Makarov
Date: Sat Mar 20 10:50:03 2021 -0400
[PR99680] Check empty constraint before using
While working on PR99454 I found that IR incorrectly processes
constraints starting with '0'..'9' and containing more one digit. It is
probably a rare event and it does not result in wrong code generation.
Simply, the generated code will be more efficient.
In any case the following patch
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99233
commit 557a0d3b1b389c46d5a8aa24e27abed4c401d17e
Author: Vladimir N. Makarov
Date: Thu Feb 25 11:20:32 2021 -0500
[PR99233] tesstsuite: Run test pr96264.c only for little endian
The test in question
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99123
The patch was successfully bootstrapped and tested on x86-64
commit b6680c2084521d2612c3a08aa01b274078c4f3e3
Author: Vladimir N. Makarov
Date: Wed Feb 24 13:54:10 2021 -0500
[PR99123] inline-asm: Don't use
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
The patch was successfully bootstrapped and tested on ppc64le, x86-64
and arm64.
commit 04b4828c6dd215385fde6964a5e13da8a01a78ba (HEAD -> master)
Author: Vladimir N. Makarov
Date: Mon Mar 8 09:24:57 2021 -0500
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99378
The patch was successfully bootstrapped and tested on x86-64.
commit e786c7547eda4edd90797f6cae0f5e6405d64773 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Fri Mar 5 11:41:25 2021 -0500
[PR99378]
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
commit f99f64f69db49ce6343d79a39eab28dcc6b91865
Author: Vladimir N. Makarov
Date: Wed Apr 14 13:21:40 2021 -0400
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
The patch was successfully bootstrapped and tested on ppc64le.
commit e0d3041c9caece8b48be016fa515747eb2746d35
Author: Vladimir Makarov
Date: Thu Feb 18 22:40:54 2021 +
[PR96264] LRA: Check output insn
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
allocno copy was being created for:
(insn 121 120 123 11 (parallel [
(set (reg:VNx2QI 217)
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
The patch was successfully bootstrapped and tested on x86-64.
commit ec4c30b64942e615b4bb4b9761cd3b2635158608 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Fri Sep 24 10:06:45 2021 -0400
Make
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627
The patch was successfully bootstrapped and tested on x86-64.
commit fab2d977e69539aad9bef81caff17de48e53aedf (HEAD -> master)
Author: Vladimir N. Makarov
Date: Fri Oct 8 10:16:09 2021 -0400
[PR102627]
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842
As the patch touches a sensitive LRA code, the patch was bootstrapped
tested on x86-64, aarch64, and ppc64.
I've committed the patch only in master branch. Later (after some
observation), I'll commit it into
On 2021-12-02 10:52, Christophe Lyon wrote:
On Thu, Dec 2, 2021 at 3:38 PM Vladimir Makarov via Gcc-patches
wrote:
On 2021-12-02 09:29, Jakub Jelinek wrote:
> On Thu, Dec 02, 2021 at 09:23:20AM -0500, Vladimir Makarov wrote:
>> On 2021-12-02 09:00, Jakub Jeli
On 2021-12-02 12:21, Vladimir Makarov via Gcc-patches wrote:
On 2021-12-02 12:06, Vladimir Makarov wrote:
So simple problem and so many details :)
This will require that long long is at least twice as large as int
everywhere, I thought you wanted to do that only when
On 2021-12-02 11:13, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 11:03:46AM -0500, Vladimir Makarov wrote:
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -2797,6 +2797,7 @@ static void
setup_allocno_priorities (ira_allocno_t *consideration_allocnos, int n)
{
int i, length, nrefs,
On 2021-12-02 12:06, Vladimir Makarov wrote:
On 2021-12-02 11:13, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 11:03:46AM -0500, Vladimir Makarov wrote:
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -2797,6 +2797,7 @@ static void
setup_allocno_priorities (ira_allocno_t
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
After some observation, if all is ok, I will commit the patch into gcc
release branches mentioned in the PR.
[PR99531] Modify
This is one more patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
The following patch fixes the test failure on ia32.
commit 4ddeae2b2777aa5136fc2bb21c15b0fcccdafece
Author: Vladimir N. Makarov
Date: Tue Dec 14 08:57:30 2021 -0500
[PR99531] Do not scan push insn for ia32 in
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
The patch was successfully bootstrapped and tested on x86-64. There is
no test as the bug occurs on GCC built with sanitizing for an existing
go test.
commit c6cf5ac1522c54b2ced98fc687e973a9ff17ba1e
Author: Vladimir
On 2021-12-02 09:00, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 08:53:31AM -0500, Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
The patch was successfully bootstrapped and tested on x86-64. There is no
test
On 2021-12-02 09:29, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 09:23:20AM -0500, Vladimir Makarov wrote:
On 2021-12-02 09:00, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 08:53:31AM -0500, Vladimir Makarov via Gcc-patches
wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla
On 2022-01-06 09:45, Richard Sandiford wrote:
This series of patches recovers the exchange2 performance lost in the
GCC 11 timeframe (at least on aarch64 and Power9 -- thanks Pat for
testing the latter).
There are 6 patches, split into two groups of 3. The first 3 are just
preparatory
On 2022-01-06 09:46, Richard Sandiford wrote:
The final index into (ira_)memory_move_cost is 1 for loads and
0 for stores. Thus the combination:
entry_freq * memory_cost[1] + exit_freq * memory_cost[0]
is the cost of loading a register on entry to a loop and
storing it back on exit from
On 2022-01-06 09:47, Richard Sandiford wrote:
color_pass has two instances of the same code for propagating non-cap
assignments from parent loops to subloops. This patch adds a helper
function for testing when such propagations are required for correctness
and uses it to remove the duplicated
1 - 100 of 179 matches
Mail list logo