https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99378
--- Comment #2 from Vladimir Makarov ---
Thank you for reporting this.
I've reproduced the bug. The fix will be ready this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #6 from Vladimir Makarov ---
(In reply to Joseph S. Myers from comment #0)
> Created attachment 50314 [details]
> preprocessed source
>
> Commit 9105757a59b890194ebf5b4fcbacd58db34ef332 ("[PR99378] LRA: Skip
> decomposing address for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> I see the function is called before selecting a particular alternative, so
> perhaps it means to care only about constraints like "X" and "" and not say
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #11 from Vladimir Makarov ---
I think I fixed the PR. Although there may be necessity for one more patch to
solve other process_address_1 issues. I did not decide this yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99461
Vladimir Makarov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #13 from Vladimir Makarov ---
*** Bug 99461 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99467
Bug 99467 depends on bug 99461, which changed state.
Bug 99461 Summary: [11 Regression] ICE in extract_constrain_insn, at
recog.c:2670 since r11-7526-g9105757a59b89019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99461
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99467
Vladimir Makarov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #14 from Vladimir Makarov ---
*** Bug 99467 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
--- Comment #6 from Vladimir Makarov ---
The patch is not enough. It seems that there are other asms in the test which
results in LRA crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #20 from Vladimir Makarov ---
I started to work on another, more safe approach to solve the problems. I hope
the patch will be ready today or tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #22 from Vladimir Makarov ---
Could you check the patch on the failed bootstraps. I have no access to
solaris machines.
Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #25 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #24)
> This can be reproduced with a minimal Ada cross-compiler, i.e. you just need
> the gnat1 compiler, the skeleton of libada and the command line:
> $(srcdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #26 from Vladimir Makarov ---
Here are my findings.
Before the patches function process_address_1 used CONSTRAINT__UNKNOWN (taken
from '=' of constraint "=T,..." and this is wrong) to check validity address.
It was invalid and LRA a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #4 from Vladimir Makarov ---
I've reproduced it too and started to work on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #6 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #5)
> Thanks Vladimir. It is indeed a problem in LRA (or triggered by it).
> We have
> 8: {[r121:DI+low(unspec[`*.LANCHOR0',%2:DI]
> 47+0x92a4)]=asm_operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #9 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #8)
> Rather than a target hook, isn't it a property of a particular constraint?
> This constraint implies "m", this one doesn't?
> Make the implies "m" behavior the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #10 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #7)
> The addition of those extra args makes clear that the function is no
> longer just testing if it is a valid address. It should be renamed.
>
I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #11 from Vladimir Makarov ---
Introducing a new memory constraint can take some time.
I guess we could switch off the offending code meanwhile because it is compiler
crash vs unoptimal generated code choice.
I'll investigate how swi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #12 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #11)
> Introducing a new memory constraint can take some time.
>
> I guess we could switch off the offending code meanwhile because it is
> compiler crash vs un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #15 from Vladimir Makarov ---
I've submitted the patch defining a new memory constraint:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566976.html
The patch itself:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99663
--- Comment #9 from Vladimir Makarov ---
Thank you for reporting this. I've reproduced this crash. ETA of the patch is
Monday at worst.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680
--- Comment #2 from Vladimir Makarov ---
Sorry for the troubles with my previous patch. I should have not be in hurry to
fix PR99663.
I'll fix it today. Jakub's patch could be a candidate but I prefer check
constraint[0] on '\0'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680
--- Comment #5 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> I was worried that letters that introduce multi-letter constraints followed
> by '\0' could be a problem too. Or do we rely on those being dropped
> already e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
--- Comment #4 from Vladimir Makarov ---
(In reply to Alex Coplan from comment #2)
> The above ICEs with just -O3 -march=armv8.2-a+sve.
Thank you for reporting. I reproduced it тоо. I think соме constraint was not
categorized rightly. It might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
--- Comment #6 from Vladimir Makarov ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> I wonder if the CT_RELAXED_MEMORY cases should be following
> on from CT_MEMORY rather than CT_SPECIAL_MEMORY. They're really
> normal memory constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99787
Vladimir Makarov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
Vladimir Makarov changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
--- Comment #5 from Vladimir Makarov ---
I've reproduced it too and started to work on it. I hope the fix will be ready
this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #17 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #16)
> (In reply to seurer from comment #15)
> > It still fails on gcc 10, though
>
> Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3?
Nob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #19 from Vladimir Makarov ---
(In reply to Richard Biener from comment #18)
> Please somebody do it quick then (not omitting necessary testing, of course).
I am working on it. It is my highest priority work. The patch is ready. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #22 from Vladimir Makarov ---
I've committed the patch to gcc-10 branch.
I also committed patch modifying the test -- see PR99233.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066
--- Comment #2 from Vladimir Makarov ---
Thank you for reporting this. I've reproduced this bug. It seems something
wrong with hard reg live range splitting. This code is complicated so I can
not say when it will be fixed but I'll do my best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #11 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> Vlad, do you plan to backport this to 10.3?
Unfortunately, a few days ago people reported a serious problem with the patch
(see PR97313). I've just submitte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #13 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #12)
> Certainly.
I've just committed it into the branch
https://gcc.gnu.org/g:70a66ff0228277b4dd89263a663c0a87eb5d782f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
--- Comment #5 from Vladimir Makarov ---
(In reply to Martin Liška from comment #4)
> Thank you Vladimir for the fix.
> Can we close it now?
There are no complaints about the patch for more a week. So I guess the PR can
be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> The IRA dump says:
> a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000
> BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000
> C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
--- Comment #9 from Vladimir Makarov ---
(In reply to Hongtao.liu from comment #6)
>
>
> Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply
> legitimate_address_p?
memory_operand does not imply legitimate_address_p. When L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870
--- Comment #2 from Vladimir Makarov ---
(In reply to Richard Biener from comment #1)
> Possibly related to the asm goto enhancements.
This test should work only for x86-64. Running it on other targets can give
an error.
So error about inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
> Started with r11-5034-g253c415a1acba50711c82693426391743ac18040
Sorry for causing this error. It is clearly my mistake. I've started to work
on this. The fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 49623 [details]
> vec-perm-indices.ii.xz
>
> The preprocessed file.
I've reproduced the problem. The emitted insn got wrong bb. The patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97954
--- Comment #2 from Vladimir Makarov ---
(In reply to Martin Liška from comment #1)
> Started with r11-5002-ge3b3b59683c1e7d3.
Before the patch, gcc just reported an error. Now it is a crash.
The problem is not the patch itself but in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #8 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> Vlad, do you plan to backport this to 10.3?
I guess so. We had enough time to test it. I don't see any complaints about
this patch. I'll backport it today
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I am trying to find the best place to fix this:
either in memory subreg elimination or in match_reload itself. I hope the fix
will be ready tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
--- Comment #3 from Vladimir Makarov ---
Thank you for reporting it.
I've started work on the PR. It seems a rare but dangerous bug and its fix
might affect many targets and will require a lot of testing but I try to fix
the PR on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #13 from Vladimir Makarov ---
Thank you for reducing the test.
I've reproduced the problem and started working on it. I think the fix will be
ready on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #15 from Vladimir Makarov ---
Created attachment 49955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49955&action=edit
a patch fixing the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #16 from Vladimir Makarov ---
(In reply to Przemyslaw Wirkus from comment #14)
> Hi Vladimir,
>
> I'm assigned to the issue and I'm working on it. I think I got the root
> cause.
> I'm in the process of creating a patch after I compl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #6 from Vladimir Makarov ---
I've reproduced the bug too. The fix will be on the next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
--- Comment #1 from Vladimir Makarov ---
Sorry, I can not reproduce this on today trunk using reint.cpp test. I guess
it is x86-64. I am using the following configuration (meaning with enabled
checking)
/home/cygnus/vmakarov/build1/gcc-git/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
--- Comment #3 from Vladimir Makarov ---
(In reply to Martin Liška from comment #2)
> It happens for s390x target, so you will need to build a cross compiler with:
> --target=s390x-linux-gnu.
Thank you, Martin. I've reproduced it on s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #21 from Vladimir Makarov ---
Additional fix for PR98722 is necessary for this PR.
4334b524274203125193a08a8485250c41c2daa9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98643
--- Comment #3 from Vladimir Makarov ---
I believe a patch for PR98722 fixes this PR too.
4334b524274203125193a08a8485250c41c2daa9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I've reproduced the bug on riscv64 and started to
work on fixing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #22 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #21)
> Additional fix for PR98722 is necessary for this PR.
>
> 4334b524274203125193a08a8485250c41c2daa9
Sorry, one more fix for PR98777 is necessary for the P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
--- Comment #7 from Vladimir Makarov ---
I've reproduced it on gcc-10 branch.
For some reason, LRA does not change register class for reload pseudo.
This bug will take some time for a fix as the fix will probably affect very
sensitive part of L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
--- Comment #9 from Vladimir Makarov ---
I've committed the patch only to the trunk. I believe the bug on the trunk is
still present but not triggered by the test.
I'll commit a bit modified patch to gcc 10 branch after some time if there is
no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701
--- Comment #11 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Vladimir Makarov from comment #9)
> > I've committed the patch only to the trunk. I believe the bug on the trunk
> > is still present but not t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97510
--- Comment #1 from Vladimir Makarov ---
I cannot reproduce this on today trunk. The bug might be fixed by some recent
patches (probably for PR98777).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
--- Comment #5 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #4)
> Vlad, is this fixed now and we can close it? It's marked as a P1, so would
> be nice to close if fixed.
I believe it is fixed and we could close the PR but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
--- Comment #6 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #5)
> Another P1 that looks like it might be fixed. Vlad, can we marked this as
> fixed?
I believe it is fixed and we could close the PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #11 from Vladimir Makarov ---
I've reproduced this bug and started to work on it. The bug is serious and
should be probably considered as P1 one. I try to fix it on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
--- Comment #7 from Vladimir Makarov ---
Created attachment 50225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50225&action=edit
A candidate patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
--- Comment #8 from Vladimir Makarov ---
I've tried different approaches to fix it. The best patch I have now is in the
attachment.
Unfortunately, the best patch results in two new failures on ppc64 (other
patches are even worse):
gcc.target/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99123
--- Comment #2 from Vladimir Makarov ---
(In reply to G. Steinmetz from comment #0)
> Affects versions down to at least r5 at -O1+.
> Testfile derived from gcc/testsuite/gcc.target/i386/20020729-1.c
> with string "1" changed to "" :
>
>
> $ gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
--- Comment #2 from Vladimir Makarov ---
(In reply to Kewen Lin from comment #1)
> Created attachment 50715 [details]
> ira:consider matching cstr in all alternatives
>
> With little understanding on ira, I am not quite sure this patch is on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I've been working on this PR. I believe the PR
reveals the problem not only for PDP11. I guess the same can happen for some
other targets.
I hope the patch will be ready
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #35 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #34)
> Seems right now DECL_NONALIASED is only used on these coverage vars and on
> Fortran caf tokens, so perhaps a quick workaround would be on the LRA side
> ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #20 from Vladimir Makarov ---
(In reply to Richard Biener from comment #14)
> Thanks for the new testcase. With -O0 (and a --enable-checking=release
> built compiler) this builds in ~11 minutes (on a Ryzen 9 7900X) with
>
> integr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
--- Comment #1 from Vladimir Makarov ---
I think the problem is that cris uses the old reload pass. Could you check the
following patch:
diff --git a/gcc/ira.cc b/gcc/ira.cc
index d0b6ea062e8..9f9af808f63 100644
--- a/gcc/ira.cc
+++ b/gcc/ira.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
--- Comment #4 from Vladimir Makarov ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to Vladimir Makarov from comment #1)
> > I think the problem is that cris uses the old reload pass. Could you check
> > the following patch:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
--- Comment #9 from Vladimir Makarov ---
(In reply to Hans-Peter Nilsson from comment #8)
> My test-run with the suggested change on top of r13-5761-g10827a92f1a8c3
> came out clean (all regressions resolved, no new ones added) so I'll close
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I'll try to fix it as soon as possible, today or
tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108145
--- Comment #6 from Vladimir Makarov ---
FYI, I think my patch did not cause this problem.
I've just check fresh trunk (w/o my patch and the compilation still fails).
So the PR probably should be still open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108141
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> The change has been reverted, so this is no longer a regression.
Just for the info. The patch I reverted resulted in wrong calculation of
pressure classes (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> If I change the testcase to following (so that it doesn't rely on
> __builtin_convertvector), it started ICEing with
> r0-122162-gb7aa4e9afcd3da4f09d6f982a663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104686
--- Comment #19 from Vladimir Makarov ---
(In reply to Richard Biener from comment #16)
> it doesn't make a difference for this testcase but profiling shows that
> allocnos_conflict_p is quite expensive so it's best to do it after the other
> co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #6 from Vladimir Makarov ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:d7b4c8feee11ea04b83f9996654c96b130588570
>
> commit r12-7449-gd7b4c8feee11ea04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961
--- Comment #2 from Vladimir Makarov ---
I've reproduced the bug. The mentioned patch is not the cause but a trigger.
The origin of the problem is actually a removal of hard reg propagation before
RA which happened about year ago.
I hope the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #9 from Vladimir Makarov ---
Cycling is the worst what can happen to compiler (even crash is better).
This is the highest priority PR right now for me. I can not say why the cycle
does not finish. It should as it works only for rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #10 from Vladimir Makarov ---
I've reproduced the bug also on the trunk. The loop in question assumes a
specific order for reload insns. In this case order of insns involving the
reload pseudos is violated because the pseudo is als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #12 from Vladimir Makarov ---
GCC-11 branch needs a bit different patch. I'll commit a modified patch to
gcc-11 branch on Friday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136
--- Comment #4 from Vladimir Makarov ---
I am just saying trivial things here that RA is a NP-complete task and there is
no optimal solution for all tests. For GCC it is even more complicated as RA
solves code selection tasks too. Basically we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
--- Comment #21 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #19)
> r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE,
> r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs.
>
> I guess there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
--- Comment #23 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #22)
> If we consider such an inline asm invalid, we could error on it, ICE is not
> the right thing. But what exactly should we error on? Alternative
I think i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #3 from Vladimir Makarov ---
(In reply to Richard Biener from comment #2)
> We need to understand the issue at least.
I think that it is not an RA problem.
IRA assigns quite reasonable registers. LRA just generates 2 reloads for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103616
--- Comment #1 from Vladimir Makarov ---
I can not reproduce ICE on this week GCC. Probably it was fixed (or switched
off) by some recent RA patch.
As for the second issue (code generation for function foo), I thought for some
time how it coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #26 from Vladimir Makarov ---
(In reply to Richard Biener from comment #7)
> make costs in a way that IRA/LRA prefer re-materialization of constants
> from the constant pool over spilling to GPRs (if that's possible at all -
> Vlad?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #27 from Vladimir Makarov ---
(In reply to Richard Biener from comment #17)
> So in .reload we have (with unpatched trunk)
>
> 401: NOTE_INSN_BASIC_BLOCK 6
> 462: ax:DF=[`*.LC0']
> REG_EQUAL 9.850689972416730997792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #13 from Vladimir Makarov ---
I think there are two code spots whose pitfalls resulted in the PR.
The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits wrong
pic low-sum address.
Another one is in lra-constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this, Jeff.
I've reproduced the bug. I hope to fix this on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #28 from Vladimir Makarov ---
Could somebody benchmark the following patch on zen2 470.lbm.
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 9cee17479ba..76619aca8eb 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #21 from Vladimir Makarov ---
(In reply to Iain Sandoe from comment #20)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Vladimir Makarov from comment #13)
> > > I think there are two code spots whose pitfalls resulted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #30 from Vladimir Makarov ---
(In reply to Richard Biener from comment #29)
> (In reply to Vladimir Makarov from comment #28)
> > Could somebody benchmark the following patch on zen2 470.lbm.
>
> Code generation changes quite a bit,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
--- Comment #3 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #2)
> NP on the timing. My biggest concern (as always) is whether or not this is
> a generic issue or a bug in the v850 target files. The former is obviously
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
--- Comment #5 from Vladimir Makarov ---
Thank you for reporting this. This problem seems not that important as it is
only about heuristic costs and might be result only in worse performance code
generation (but might be in better code -- it is
1 - 100 of 203 matches
Mail list logo
