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=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=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=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=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=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=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=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=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 #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 #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 #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 #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 #4 from Vladimir Makarov ---
I've reproduced it too and started to work on it.
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=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 #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 #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=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=99454
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
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=99467
Vladimir Makarov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
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=99422
--- Comment #13 from Vladimir Makarov ---
*** Bug 99461 has been marked as a duplicate of this bug. ***
|--- |DUPLICATE
CC||vmakarov at gcc dot gnu.org
--- Comment #3 from Vladimir Makarov ---
It is a duplicate of PR99422. With patch for PR99422, the crash is gone.
*** This bug has been marked as a duplicate of bug 99422 ***
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=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 #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=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=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=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=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=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=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=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=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=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=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 #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=97684
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
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=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=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=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=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=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=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=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=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 #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=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=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=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=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=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=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=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=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=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=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=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=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=87767
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
--- Comment #5 from Vladimir Makarov ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> (In reply to Vladimir Makarov from comment #3)
> > I looked at this problem.
> >
> > All assignments are done in IRA (LRA does not change them). We ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
--- Comment #3 from Vladimir Makarov ---
I looked at this problem.
All assignments are done in IRA (LRA does not change them). We can not make a
better assignment because scratches do not permit to store any preferences from
instruction constra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #13 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #12)
> (In reply to Vladimir Makarov from comment #11)
> > I just expressed my point of view to the bottom-up approach. If somebody
> > implements any new RA a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #11 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #10)
> Hi Vlad,
>
> Just curious if you had a chance to think about an approach to this that
> would be acceptable.
Sorry for not working on this issue more a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #1 from Vladimir Makarov ---
Jakub, thank you for working on the PR and providing the test case.
It seems to me that the problem occurs in inheritance sub-pass of LRA. It is a
very complicated sub-pass. Making a fix and testing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94663
--- Comment #2 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
> I bet IRA is confused by the subregs.
>
No, I don't think it is the case here.
(insn 19 18 20 4 (parallel [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
--- Comment #27 from Vladimir Makarov ---
(In reply to Christophe Lyon from comment #26)
> For what CPU did you configure GCC?
> With today's trunk I still see the same code as in comment #24.
>
> I can get the same code as you have in comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
--- Comment #25 from Vladimir Makarov ---
Sorry, I can not reproduce this. With today trunk I have for pr45701-1.c (-Os
-mthumb):
history_expand_line_internal:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94298
--- Comment #5 from Vladimir Makarov ---
I think that the root of the problem is that IRA on register cost calculation
sub-pass chooses memory for the pseudo.
It happens because the current algorithm (which is just an adoption of old
recglass.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
--- Comment #5 from Vladimir Makarov ---
I found the problem. LRA reused the same insn alternative when mem subreg was
changed.
The patch will be ready today or tomorrow at worst.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
--- Comment #4 from Vladimir Makarov ---
Thank you the reduced test. I've started to work on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
--- Comment #11 from Vladimir Makarov ---
Jakub, thank you for the analysis. I've been working on this PR too. I hope
the patch will be ready on Friday or at the beginning of the next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #39 from Vladimir Makarov ---
I've reverted the patch in trouble:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=5dc1390b41db5c1765e25fd21dad1a930a015aac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #29 from Vladimir Makarov ---
Sorry for all the troubles with my latest patch and thank you for fair
criticism. I've decided to revert the patch as soon as git starts working.
I'll work to find a better solution after this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #33 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #32)
> So it sounds like this helps for targets with tiny register sets?
I guess it helps for any target but of course more for ones with smaller
register set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #31 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #30)
> r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
This heuristic avoid creating small gaps in hard reg file which prevent
assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #13 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #4)
> I'm CCing Vlad, since I need some guidance/help for some LRA questions.
>
> Vlad, do you have some guidance on what should be done when we see
> an address l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
--- Comment #3 from Vladimir Makarov ---
I checked the new results
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.240.0
It seems the patch solved the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #4 from Vladimir Makarov ---
> Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> -flto.
>
I don't see how these two patches *directly* resulted in miscompilation.
Although it might trigger some latent bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93561
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. It seems the bug did not manifested itself
before as the most targets have virtual hard registers as the last hard regs.
I'll commit your patch today.
Thank you again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
--- Comment #1 from Vladimir Makarov ---
Thank your for reporting this.
I've changed RA heuristics. It is very rare case when you change heuristics
and there is no one SPEC benchmark with performance degradation. Usually some
benchmarks improv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
--- Comment #16 from Vladimir Makarov ---
(In reply to rsand...@gcc.gnu.org from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > I think what matters is whether the new asm for those is the same or better
> > than before. If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
--- Comment #12 from Vladimir Makarov ---
(In reply to Christophe Lyon from comment #10)
> (In reply to Jeffrey A. Law from comment #9)
> > Fixed by Vlad's patch on the trunk.
>
> This patch causes regressions:
> aarch64:
>
I've committed one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #10 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #9)
> Vlad, any thoughts on this?
A pseudo in the loop happens to be spilled. So the pseudo is changed onto
its equivalence which is an invariant to the loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320
--- Comment #7 from Vladimir Makarov ---
I've committed a patch solving PR91333. The patch also solves the current PR.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2a07345c4f8dabc286fc470e76c53473e5bc3eb7
So I guess we can close the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
--- Comment #4 from Vladimir Makarov ---
(In reply to Andreas Krebbel from comment #3)
> Created attachment 47714 [details]
> IRA EH fix - only when added at start of BB
>
> A probably better version of the fix. This version only reverts the
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
--- Comment #6 from Vladimir Makarov ---
(In reply to Marc Glisse from comment #5)
>
> However, if I add -mavx, I get
>
> vmovapd %xmm0, %xmm2
> vmovapd %xmm1, %xmm4
> vmovapd %xmm1, %xmm0
> vaddsd %xmm0, %xmm4, %xmm0
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 10 20:45:19 2020
New Revision: 280138
URL: https://gcc.gnu.org/viewcvs?rev=280138&root=gcc&view=rev
Log:
2020-01-10 Vladimir Makarov
PR inline-asm/93027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
--- Comment #2 from Vladimir Makarov ---
Sorry, I did a mistake in PR number and automatic commits reporting did not
work.
Here are the patches fixing the PR:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=280133
https://gcc.gnu.org/vie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207
--- Comment #2 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 10 20:18:00 2020
New Revision: 280135
URL: https://gcc.gnu.org/viewcvs?rev=280135&root=gcc&view=rev
Log:
2020-01-10 Vladimir Makarov
PR inline-asm/93207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207
--- Comment #1 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 10 20:07:45 2020
New Revision: 280133
URL: https://gcc.gnu.org/viewcvs?rev=280133&root=gcc&view=rev
Log:
2020-01-10 Vladimir Makarov
PR inline-asm/93207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
--- Comment #1 from Vladimir Makarov ---
Thank you for the report. I've started working on it. As changes in
constraint processing needs a lot of testing, I think the patch will be read on
Friday or on the next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Dec 19 21:59:47 2019
New Revision: 279596
URL: https://gcc.gnu.org/viewcvs?rev=279596&root=gcc&view=rev
Log:
2019-12-19 Vladimir Makarov
PR target/92905
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #5 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> Note, it isn't about , using rm in the first alternative of the
> reverted define_insn works well too, as well as swapping the alternatives
> (that is in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
--- Comment #11 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Dec 10 22:07:57 2019
New Revision: 279204
URL: https://gcc.gnu.org/viewcvs?rev=279204&root=gcc&view=rev
Log:
2019-12-10 Vladimir Makarov
PR rtl-optimization/92796
101 - 200 of 879 matches
Mail list logo
