http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com ---
(In reply to Zhendong Su from comment #2)
(In reply to H.J. Lu from comment #1)
It is caused by r202468.
So it may have been a dup of 58418?
Yes, it is a duplication.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
--- Comment #6 from Vladimir Makarov vmakarov at redhat dot com ---
On 13-08-22 10:11 AM, rearnsha at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58110
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com ---
Thanks, Ondrej and Jan. GCC with reload generates code with the same problem.
I mentioned on RA BOF that we should look at postreload.c and postreload-gcse.c
to figure out what
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
--- Comment #5 from Vladimir Makarov vmakarov at redhat dot com ---
I've started this work. But unfortunately, i have too many things on my plate
now. I was too optimistic. Now I can say only that I am planning to fix it on
stage1 (so the fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
--- Comment #11 from Vladimir Makarov vmakarov at redhat dot com ---
I don't see a code degradation because of LRA. Here what I got using gcc4.8
branch compiler with options -O3 -finline-functions -D_REENTRANT
-Wno-long-long -W -Wall -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57046
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56999
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847
--- Comment #9 from Vladimir Makarov vmakarov at redhat dot com 2013-04-18
20:10:34 UTC ---
I am still working on this. I have a patch solving the problem but I'd like to
try other solutions too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
--- Comment #7 from Vladimir Makarov vmakarov at redhat dot com 2013-02-07
20:08:47 UTC ---
(In reply to comment #6)
Actually, that one doesn't really work, because we have pseudo rather than
hard
reg at that point, which will never
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55141
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2012-10-26
22:49:23 UTC ---
LRA reuses stack memory much better than reload (in all modes but especially
in -O0). May be that is the reason of the var-tracking problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2012-10-26
22:57:38 UTC ---
(In reply to comment #2)
LRA reuses stack memory much better than reload (in all modes but especially
in -O0). May be that is the reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55050
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2012-05-10
18:30:19 UTC ---
I've tried a recent trunk on gcc63 of the compiler farm with -O0. The
compilation takes about 300sec. I checked also gcc-4.3 (this last version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2012-04-29
00:08:54 UTC ---
I'll look at this PR in a week.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52208
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49800
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2012-02-02
18:33:34 UTC ---
I am working on it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
--- Comment #17 from Vladimir Makarov vmakarov at redhat dot com 2012-01-19
20:42:57 UTC ---
The problem was in building CFG loops which took the most of time. CFG
loops were built even if we don't use regional allocation as for -O0.
I'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176
--- Comment #9 from Vladimir Makarov vmakarov at redhat dot com 2011-12-13
20:04:04 UTC ---
(In reply to comment #0)
Created attachment 25088 [details]
After expanding 4.7 contains:
(insn 52 51 53 6 (set (reg:QI 83 [ D.2723
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21617
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50775
--- Comment #6 from Vladimir Makarov vmakarov at redhat dot com 2011-12-04
04:09:06 UTC ---
(In reply to comment #5)
(In reply to comment #4)
Wrong profitable hard regs calculation for register files requiring aligned
start register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50775
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-11-28
21:48:20 UTC ---
(In reply to comment #2)
Also, I have a question about the following fields of `ira_allocno':
/* The number of objects tracked in the following
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
--- Comment #7 from Vladimir Makarov vmakarov at redhat dot com 2011-11-24
03:45:24 UTC ---
As for stack allocation. crtl-stack_realign_needed == 1 results in
frame_pointer_needed:=1 in ira.c::ira_setup_eliminable_regset. I don't
remember
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50146
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #14 from Vladimir Makarov vmakarov at redhat dot com 2011-08-19
16:12:48 UTC ---
(In reply to comment #11)
(In reply to comment #10)
movq%rdi, %rdx
mulx%rsi, %rax, %rsi
movq%rsi, %rdx
ret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49890
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #10 from Vladimir Makarov vmakarov at redhat dot com 2011-08-18
18:24:42 UTC ---
(In reply to comment #9)
With revision 177865 + MULX change, I got
[hjl@gnu-6 pr50107]$ cat uti-2.i
unsigned __int128 test_mul_64 (unsigned long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2011-08-17
17:16:11 UTC ---
I guess something wrong with hard register preferencing for multi-register
pseudos in ira-color.c::ira_assign. I believe it works fine for one-register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #6 from Vladimir Makarov vmakarov at redhat dot com 2011-08-17
22:21:13 UTC ---
(In reply to comment #4)
Created attachment 25038 [details]
A patch
This patch generates:
movq%rdi, %rdx
mulx%rsi, %r10, %r9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-08-16
17:27:12 UTC ---
(In reply to comment #3)
Hmmm. Is it possible to make the INT/memory/whatever decision based on move
costs? Or use a target hook to supply a hint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2011-08-16
02:05:02 UTC ---
After thorough investigation of the problem I came to a conclusion that fixing
it in IRA requires to form regions on pseudo mode usage too (besides just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-05-13
15:34:39 UTC ---
(In reply to comment #3)
(In reply to comment #2)
Vlad, this is an abort in setup_pressure_classes which apparently is totally
broken for sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-05-12
17:57:58 UTC ---
(In reply to comment #2)
Vlad, this is an abort in setup_pressure_classes which apparently is totally
broken for sparc -msoft-float.
I found the wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455
--- Comment #6 from Vladimir Makarov vmakarov at redhat dot com 2011-04-13
15:21:23 UTC ---
I found one problem with reg equivalences. They were just ignored. It is a
result of bad merging the big IRA patch and changes in IRA for last half year
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-04-11
17:11:37 UTC ---
The new big IRA patch just triggered a latent reload bug.
The code in question is in function reload_as_needed
/* If this was an ASM, make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-04-11
18:44:59 UTC ---
There is typo in a loop condition resulting in taking hard registers of
LIM_REG_CLASS which happens a garbage for VAX.
I'll send a patch soon.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48272
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-04-07
21:22:49 UTC ---
(In reply to comment #2)
Confirmed (nice non-sensical set of options, btw.)
The problem is that register pressure code is not prepared for new insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48435
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48380
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48381
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48367
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-03-30
23:17:58 UTC ---
I've started to work on this. Probably it will take day or two to fix it is
hard to find a wrong code in a big program as apsi.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48367
--- Comment #6 from Vladimir Makarov vmakarov at redhat dot com 2011-03-31
01:05:33 UTC ---
The problem was in a typo in ira-costs.c which in some cases results in
assigning INT_MAX to memory_cost and as consequence ALL_REGS to some allocnos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48331
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48345
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2011-03-29
23:59:08 UTC ---
(In reply to comment #0)
It seems that ira-color.c:assign_hard_reg chooses a register
of which corresponding bit of ira_prohibited_class_mode_regs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48345
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-03-30
00:49:50 UTC ---
(In reply to comment #3)
Thanks! Is
PR rtl-optimization/48345
* ira-color.c (assign_hard_reg): Skip prohibited hard registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48342
--- Comment #1 from Vladimir Makarov vmakarov at redhat dot com 2011-03-30
01:26:26 UTC ---
I've just submitted a patch for approval to solve the problem. I hope it will
be fixed soon.
Thanks for the report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46920
--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2010-12-14
16:02:09 UTC ---
(In reply to comment #2)
To generate the proposed code, we should assign r12 to p63. IRA marks p63
conflicting with r12 because DF-infrastructure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46920
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
--- Comment #10 from Vladimir Makarov vmakarov at redhat dot com 2010-12-10
15:45:33 UTC ---
(In reply to comment #9)
(In reply to comment #5)
It should work for x86_64, not necessarily i?86.
Do you mean -fsched-pressure should be able
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44249
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2010-11-24
17:40:56 UTC ---
Reload creates additional insn for insn
(insn 9 7 11 2 (parallel [
(set (reg:DI 71)
(lshiftrt:DI (reg/v:DI 60 [ tag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov
--- Comment #23 from vmakarov at redhat dot com 2010-09-14 15:46 ---
(In reply to comment #22)
Fixed everywhere but on 4.3 branch.
Maybe commit the patch there too?
I think there is a smaller probability that this bug occurs in gcc4.3 because
it is based on the old RA. IRA uses
--- Comment #9 from vmakarov at redhat dot com 2010-09-08 17:44 ---
The problem is in that pseudos (r121 in our case) spilled by IRA are
not added to live_throughout of reload chain. As the result,
pseudo_forbidden_regs are not set up for such pseudos and they can get
a hard registers
--- Comment #9 from vmakarov at redhat dot com 2010-09-08 20:06 ---
(In reply to comment #8)
(In reply to comment #7)
Is this still a bug then? Should ira-share-spill-slots be automatically
disabled for the caller function when a callee function can return twice?
I've never
--- Comment #17 from vmakarov at redhat dot com 2010-09-07 18:03 ---
(In reply to comment #16)
I just noticed that even in the complete absence of reload inheritance, the
allocate_reload_reg routine performs free_for_value_p checks, and therefore
implicitly takes reload ordering
--- Comment #15 from vmakarov at redhat dot com 2010-09-03 20:45 ---
(In reply to comment #14)
Ulrih, I've just wanted to post the following when I found that you already
posted analogous conclusion. I should have been on CC to see your comment
right away. The problem is really
--- Comment #12 from vmakarov at redhat dot com 2010-09-01 18:06 ---
(In reply to comment #10)
(insn 1407 1405 1406 78
/mnt/b1/src/linux/set64/arch/x86/include/asm/cmpxchg_32.h:72 (set (reg:SI 2
cx)
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -28
--- Comment #1 from vmakarov at redhat dot com 2010-05-18 19:06 ---
It will be fixed by IRA without cover classes which I am working on. The code
is planned to be included in gcc4.6.
For older versions, it should be fixed in reload because I believe it is a
hidden reload bug
--- Comment #4 from vmakarov at redhat dot com 2010-05-18 21:40 ---
Thanks for reporting the problem. The problem has no effect on generated
code whatever initialization is used. The code in question tries to get basic
block for BARRIER which is wrong. Whatever it gets basic block
--- Comment #3 from vmakarov at redhat dot com 2010-05-10 15:22 ---
It is caused by revision 152533:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00182.html
If it is so, the patch triggered some reload bug IMO. The patch itself was
very safe because it resulted in creation
--- Comment #12 from vmakarov at redhat dot com 2010-05-07 17:49 ---
When allocno is finished, its some info is propagated into upper allocno.
When several allocnos with same regno are finished, info can be propagated
directly to survived upper allocno or through one allocno
--- Comment #10 from vmakarov at redhat dot com 2010-03-23 18:45 ---
(In reply to comment #5)
Still I'll investigate a bit more why there are a lot of unexpected spills
during assignment with -mvsx for the current code.
The problem is in that part of VSX_REGS (altivec regs) does
--- Comment #5 from vmakarov at redhat dot com 2010-03-22 22:16 ---
(In reply to comment #0)
In the enclosed test case, it generates the following spills for the options:
-O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 117 stfs, 139 lfs
-O3 -ffast-math -mcpu=power5 -maltivec: 80 stfs
--- Comment #6 from vmakarov at redhat dot com 2010-03-22 22:20 ---
(In reply to comment #4)
FWIW, I seem to get considerably worse code from mainline than you -- for -O3
-ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns
(compared to 117 139 respectively
--- Comment #10 from vmakarov at redhat dot com 2010-02-10 17:02 ---
The big chunk of regmove which did the same what IRA is capable to do was
removed when IRA was merged.
There are still a lot of important transformations (like dealing with
increments, sign/zero extensions etc
--- Comment #11 from vmakarov at redhat dot com 2010-02-10 17:15 ---
(In reply to comment #8)
Thanks, we should see if this solves the AMMP problem in a day or two.
Are you going to look at the related PR42961? Without the regmove hunk
it does not happen at AMMP but it likely
--- Comment #6 from vmakarov at redhat dot com 2010-02-09 19:56 ---
The patch which I'll send in a few minutes solves the problem. The patch
avoids the creation of shuffle copies if an involved operand should be bound to
some other operand in the current insn. The test code
--- Comment #4 from vmakarov at redhat dot com 2010-02-06 00:57 ---
I have a patch which solves the problem and analogous problem that Jeff
recently sent me.
I just need a time to do some benchmarking. If everything is all right, I'll
submit the patch probably on Monday.
--
http
--- Comment #3 from vmakarov at redhat dot com 2010-02-03 18:57 ---
This is a rare case when the algorithm works the same whatever values are in
memory. Roughly speaking, if the value is not as expected (for example a
garbage) the value is set up to what it needed. If it is one
--- Comment #10 from vmakarov at redhat dot com 2010-01-29 20:33 ---
Jeff, I saw analogous problem when I worked on improving IRA performance. I
checked the approach you are proposing. But it works considerably worse on
SPEC2000. Finally, I found that the best conflicting cost
--- Comment #21 from vmakarov at redhat dot com 2010-01-29 21:54 ---
Thanks everyone who works on the bug.
I am sorry that the bug was really introduced by my patch more accurately by
the part which should fix reload crashes when the 1st scheduling works for some
targets. The patch
--- Comment #8 from vmakarov at redhat dot com 2009-10-30 21:57 ---
Unfortunately, not yet because I had some failures after applying the patch. I
postponed work on this but now I have time to continue the work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
1 - 100 of 176 matches
Mail list logo
