https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103616
--- Comment #8 from Vladimir Makarov ---
I looked at the generated code and I see only one issue with func foo:
void foo (void)
{
double d = 0.0, e = 7.8;
__asm ("# %0 %1" : : "m" (d), "m" (e));
}
for which GCC generates:
movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270
--- Comment #3 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #2)
> Thank you for reporting this. I am working on analogous PR119285. I think
> the fix will be ready on this week.
Unfortunately, the patch for PR119285 di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270
--- Comment #2 from Vladimir Makarov ---
Thank you for reporting this. I am working on analogous PR119285. I think the
fix will be ready on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119285
--- Comment #1 from Vladimir Makarov ---
I can not reproduce it on Intel (13600K). GCC with patch and without the patch
has the same score for lbm_s (11.4). But I see big lbm_s code increase with
the patch (+0.87%). And this is suspenseful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113076
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101507
--- Comment #2 from Vladimir Makarov ---
Sorry, I've tried gcc-12, gcc-13, gcc-14, trunk dated by Aug 1, and today trunk
but I did not managed to reproduce the error.
Probably, it was fixed by some LRA patch (there were a lot of them since 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #14 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #13)
> The inline asm stresses the RA to the maximum, it needs 6 registers, di, cx,
> ax + 3 others and sp is fixed and bp is used as frame pointer.
> But at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116336
--- Comment #6 from Vladimir Makarov ---
(In reply to Sam James from comment #5)
> This works for me on trunk now. I assume Vlad's fix for PR116234 may have
> done it.
Yes, exactly.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=decc6c0d4d909c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
--- Comment #6 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> Can't it just look at the present insn and if it is no longer asm but
> NOTE_INSN_DELETED, ignore it?
RA keep erroneous asm goto (for keeping CFG correctnes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> So, either remove that call too, or move it into lra_asm_insn_error before
> the insn has been deleted. Vlad, I'll defer this to you.
Sorry for the issues w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #18 from Vladimir Makarov ---
Created attachment 60549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60549&action=edit
Reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #17 from Vladimir Makarov ---
The bug seems like wrong repeated interaction hard reg live range splitting and
inheritance. I'll try to make a patch and hope to fix it on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118610
--- Comment #2 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #1)
> Indeed, I have reopened PR rtl-optimization/118067
Sorry, I can not reproduce it with today trunk for sparc64 with -m32 and -m64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118611
--- Comment #7 from Vladimir Makarov ---
I worked on this issue this week. I tried several approaches. I added the best
patch as an attachment. The patch changes an order of coloring allocnos in one
thread.
Unfortunately, although the patch s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118611
--- Comment #5 from Vladimir Makarov ---
Created attachment 60488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60488&action=edit
Patch solving the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
--- Comment #7 from Vladimir Makarov ---
I've reproduced the bug and started to work on it. It looks like bug in
combination of inheritance and rematerialization. I'll try to fix it on this
week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116234
--- Comment #11 from Vladimir Makarov ---
(In reply to Sam James from comment #10)
> Vlad, could you take a look at this and PR116336 when you get a chance (not
> sure if there's others, there's definitely a few LRA compare-debug issues)?
> We t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #16 from Vladimir Makarov ---
Created attachment 60316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60316&action=edit
Machine-dependent patch solving the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #15 from Vladimir Makarov ---
I gave up on fixing the problem in LRA. Taking operand and insn
predicates into account is a wrong approach. It results in many new
test failures. As an example, for insn with operand 1 equivalent to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #14 from Vladimir Makarov ---
(In reply to Richard Biener from comment #12)
> Re-confirmed.
>
> +FAIL: gcc.target/i386/force-indirect-call-2.c scan-assembler-times
> (?:call|jmp)[ \\t]+\\*% 3
> +FAIL: gcc.target/i386/pr91384.c scan-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #12 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #11)
>
> With the test case, rld_mode is SDmode and our
> secondary_memory_needed_mode(SDmode) returns DDmode for reasons described
> above. However, newly added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
--- Comment #8 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > I cannot get the testcase to fail at all. Please give a failing command
> > line?
>
> I just used -O2 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
--- Comment #3 from Vladimir Makarov ---
(In reply to Andrew Pinski from comment #2)
> I wonder if the patch in r15-2810-g3c67a0fa1dd39a3378deb854a7fef0ff7fe38004
> (which was reverted due to a bootstrap failure on aarch64) fixes this one
> too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118560
--- Comment #5 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> And self-recursion isn't really needed, even
> struct { _Decimal32 a; } b;
> void foo (int, _Decimal32);
>
> void
> bar (int, _Decimal32 d)
> {
> foo (1, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #11 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #9)
> Unfortunately, the testcase still fails when -mtune=k8 is added to compile
> flags:
>
>
Thank you, Uros.
I tried to avoid finding longer reload loops but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #7 from Vladimir Makarov ---
I've been working on thr PR this week. The case is complicated as it contains
cycle of reloads of more one step length. LRA has a mechanism to avoid
choosing insn alternatives which can results in a loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #8 from Vladimir Makarov ---
I reverted the 1st patch variant for PR117248 which resulted in this PR.
I submitted a different patch for PR117248 which does not create new failures
for libgo tests on arm.
Still it would be nice to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #23 from Vladimir Makarov ---
(In reply to GCC Commits from comment #15)
> The master branch has been updated by Vladimir Makarov
> :
>
> https://gcc.gnu.org/g:75e7d1600f47859df40b2ac0feff5a71e0dbb040
>
> commit r15-5997-g75e7d1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #6 from Vladimir Makarov ---
I've tried arm GCC before and after the patch. I see failures before the patch
too (e.g. net failed with the same wrong address or nil dereference as crypto)
although, I should acknowledge, less than af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #18 from Vladimir Makarov ---
(In reply to John David Anglin from comment #16)
> Things are improved but a similar error occurs in the second umod:SI
> call in /testsuite/gcc.c-torture/execute/arith-rand-ll.c:
>
>
> (insn 341 339 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
--- Comment #11 from Vladimir Makarov ---
I've reproduced it and started to work on it. I think the fix will be ready
during the next 2 days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #13 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #12)
>
> I see. Thank you. I've reproduced it with using -mlra.
This case is really non-trivial and involves inheritance. Also the live
analysis in LRA af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #12 from Vladimir Makarov ---
(In reply to John David Anglin from comment #11)
> LRA is not yet enabled by default on hppa. To enable, use "-mlra" option
> or hack pa.opt to enable by default:
>
> mlra
> Target Var(pa_lra_p) Init(1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #10 from Vladimir Makarov ---
(In reply to John David Anglin from comment #7)
>
> Compile command:
> /home/dave/gnu/gcc/objdir/./prev-gcc/cc1plus -fpreprocessed
> tree-vect-slp.ii -quiet -dumpbase tree-vect-slp.cc -dumpbase-ext .cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
--- Comment #6 from Vladimir Makarov ---
(In reply to John David Anglin from comment #5)
> I'm working on trying to split the code after reload.
OK. But there is a still LRA bug which incorrectly makes r25 dead before the
division insn and anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
--- Comment #4 from Vladimir Makarov ---
(In reply to John David Anglin from comment #3)
> I suspect explicitly setting hard registers prior to reload confuses
> LRA:
>
> ;;; Division and mod.
> (define_expand "divsi3"
> [(set (reg:SI 26) (ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
--- Comment #9 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > PR117105 exhibits the same underlying probem with much smaller testcase.
>
> I started to work on these 2 PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
--- Comment #8 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #7)
> PR117105 exhibits the same underlying probem with much smaller testcase.
I started to work on these 2 PRs. I think the fix to be ready on the beginning
of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #11 from Vladimir Makarov ---
I consider it is a LRA bug.
We have
281: {r360:DI=~227:DI&[r363:SI+r362:SI];clobber flags:CC;}
and choose alternative "(0) &r (1) r (2) o"
LRA assigns (hr0,hr1) to spilled p227, then assigns (hr4,h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78664
--- Comment #2 from Vladimir Makarov ---
During register assignment subpass LRA processes hard regs from
ira_class_hard_regs. Under the same conditions (e.g. costs), LRA chooses regs
processed first.
ira_class_hard_regs contains regs according
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #11 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #10)
> Vlad, do you plan to backport this to 13.3? One of the 2 release blockers
> we have for that release.
Ok, I'll port it to releases/gcc-13 branch today. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
--- Comment #5 from Vladimir Makarov ---
I've started to work on this PR. I hope a patch will be ready on this or the
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
--- Comment #3 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #2)
> (In reply to Vladimir Makarov from comment #1)
> > (In reply to Tamar Christina from comment #0)
> > > The documentation for ^ states:
> >
> > If it works f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #9 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #7)
>
>
> Please note that the insn is defined as:
>
> (define_insn_and_split "*andn3_doubleword_bmi"
> [(set (match_operand: 0 "register_operand" "=&r,r,r")
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #6 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #4)
> An interesting observation, when the insn is defined only with problematic
> alternative:
>
> (define_insn_and_split "*andn3_doubleword_bmi"
> [(set (match_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
--- Comment #1 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #0)
> The documentation for ^ states:
>
> "This constraint is analogous to ‘?’ but it disparages slightly the
> alternative only if the operand with the ‘^’ need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #5 from Vladimir Makarov ---
After some considerations, I've decided to fix it in the scheduler.
Such approach solves the problem for all targets and schedulers, still
permitting live range shrinkage (important for space optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> BTW, with additional -mno-red-zone there is still movement of these insns,
>
The problem is even bigger. Live range splitting uses a standard insn
dependen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #11 from Vladimir Makarov ---
My finding is that RA is not a problem for GCC speed with -O1 and up.
RA in -O0 does really consume a big portion of GCC compiler time. The
biggest part of RA in -O0 is actually spent in life analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
--- Comment #7 from Vladimir Makarov ---
(In reply to Maxim Kuvyrkov from comment #5)
>
> Where did you see the timeouts, btw?
Sorry, I glanced at c logs and interpreted it wrongly. Please, discard my
previous comment.
I should been more accu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
--- Comment #4 from Vladimir Makarov ---
(In reply to Maxim Kuvyrkov from comment #3)
> Hi Vladimir,
>
> Could you take a look at this, please?
I already got a message from automatic linaro tester yesterday about the new
test failures and looke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
--- Comment #7 from Vladimir Makarov ---
I believe this PR was recently fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a729b6e002fe76208f33fdcdee49d6a310a1940e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
--- Comment #15 from Vladimir Makarov ---
The patch resulted in 2 new PRs about ICE when building glibc. So I reverted
the patch.
I'll continue work on this PR right after the winter holidays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113098
--- Comment #1 from Vladimir Makarov ---
The patch causing this was reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113097
--- Comment #1 from Vladimir Makarov ---
Joseph, thank you for reporting this. I've just reverted the patch causing
this.
I'll use this report for work on another version of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
--- Comment #12 from Vladimir Makarov ---
I've been working on the PR this week. The problem for this case is in that
for subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112875
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> Started with r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
I reproduced it and hope to fix it today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #5)
> Just changing
> --- i386.md.xx2023-11-22 09:47:22.746637132 +0100
> +++ i386.md 2023-11-22 20:38:07.216218697 +0100
> @@ -9984,7 +9984,7 @@
>[(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> Is this backportable to release branches or too risky?
I don't think it is risky. LRA was designed to have unshared rtl. So copying
rtl in LRA is not risky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
--- Comment #7 from Vladimir Makarov ---
For last 2 weeks I pushed several patches for better dealing with equivalences
in RA.
It seems the patches solves the current PR. I checked the test code generation
for loongarch and aarch64 and did not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #9 from Vladimir Makarov ---
(In reply to Sergei Trofimovich from comment #8)
> bootstrap with default options did not fail for me either. I had to use
> --enable-checking=release to trigger the failure. I wonder if it exposes the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #7 from Vladimir Makarov ---
Sorry for inconvenience because of my patch.
I reproduced the bug with the reproducer using stage1 gcc although strangely
the standard bootstrap works ok for me on i686 debian.
I think I know the reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
--- Comment #6 from Vladimir Makarov ---
(In reply to Andrew Pinski from comment #4)
> But r1 is the argument register.
It is even worse, r1 is a stack pointer. Still the compilation should not
finish by LRA failure.
I've just started to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
--- Comment #3 from Vladimir Makarov ---
Sorry for the inconvenience caused by the patch. I reverted this patch
yesterday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
--- Comment #4 from Vladimir Makarov ---
I've reproduced the bug. The problem is in combination of splitting pseudo live
range and sharing rtl.
I hope to fix this on the next Monday or Tuesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
--- Comment #1 from Vladimir Makarov ---
Unfortunately, I did not manage to reproduce the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111225
--- Comment #3 from Vladimir Makarov ---
I've reproduced the bug.
Just removing `else if (spilled_pseudo_p (op))` for CT_SPECIAL_MEMORY will
break a lot targets but this is right that this code is a reason for the bug.
I have ideas how to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #5 from Vladimir Makarov ---
(In reply to Georg-Johann Lay from comment #4)
>
>
> So are you saying that the bug is actually in lower-subreg.cc ?
No. lower subreg is fine.
Sorry to be unclear. To generate a better code for the cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #3 from Vladimir Makarov ---
I worked on avr issues quite some time. And here is my findings.
Before IRA we have start of BB2:
;; lr in14 [r14] 15 [r15] 16 [r16] 17 [r17] 18 [r18] 19 [r19] 20 [r20]
21 [r21] 22 [r22] 23 [r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
--- Comment #4 from Vladimir Makarov ---
Thank you for providing the test case.
To be honest I don't see why assigning to hr3 to r134 is better.
Currently we have the following assignments:
hr9->r134; hr3->r173; hr3->r124
and the related pref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041
--- Comment #4 from Vladimir Makarov ---
I believe it is the same problem as PR110215 which was solved recently by
checking whether pseudo values are used in the exception handler and the
handler does not return control flow back to the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215
--- Comment #4 from Vladimir Makarov ---
(In reply to Richard Biener from comment #3)
>
>
> We don't have any pass after reload that would perform loop invatiant motion,
> I'm not sure how this situation is handled in general in RA - is a post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #16 from Vladimir Makarov ---
Sam, thank you for your help. I've reproduced the problem on your machine.
The fix most probably will be ready this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #9 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #8 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #21 from Vladimir Makarov ---
(In reply to CVS Commits from comment #20)
> The releases/gcc-12 branch has been updated by Vladimir Makarov
> :
>
> https://gcc.gnu.org/g:88792f04e5c63025506244b9ac7186a3cc10c25a
>
>
The trunk with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #20 from Vladimir Makarov ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce
>
> commit r13-6846-g0d9e52675c0091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #15 from Vladimir Makarov ---
I've reproduced hanging up but for the particular commit. I also reproduced
internal compiler error on the current master.
I'll try to fix the both problems on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #21 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #20)
> That LGTM, but Vlad is the maintainer here...
It looks ok for me too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #14 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #13)
> (In reply to Peter Bergner from comment #12)
> > I'll try moving the test up earlier and testing with that.
>
> So this fixes the ICEs on the two test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #9 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> So perhaps:
> --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100
> +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100
> @@ -5020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #6 from Vladimir Makarov ---
Peter, thank you for reporting. I'll try to fix it today or revert it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #6 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Vladimir Makarov from comment #4)
>
> > So I think the current patch is probably an adequate solution.
>
> Perhaps the compiler should also try t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #4 from Vladimir Makarov ---
The complete solution would be running combine pass also after LRA. I am not
sure how frequently the 2nd pass will improve the code. Also probably it might
create some troubles the fix of which will requ
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=108999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
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=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=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=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 #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=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=103541
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
1 - 100 of 203 matches
Mail list logo
