--- Comment #8 from carrot at google dot com 2009-05-04 10:08 ---
Sorry for my ignorance to gcc. What types of instructions reload will add?
Spilling and loading registers? and more?
By reading the the implementation of thumb_far_jump_used_p() I can get the
conclusion that if reload
--- Comment #10 from carrot at google dot com 2009-05-05 15:32 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Sorry for my ignorance to gcc. What types of instructions reload will add?
> > Spilling and loading registers? and more?
> >
> That's
ct
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-li
--- Comment #1 from carrot at google dot com 2009-05-31 02:42 ---
Created an attachment (id=17940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17940&action=view)
test case to show the opportunity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40314
--- Comment #2 from carrot at google dot com 2009-05-31 02:51 ---
There are a lot of such opportunities in mcf from SPEC CPU 2006.
One possible implementation is to add a pass before cse. In the new pass it
should detect insn patterns like:
(set r200 400) # 400 is
--- Comment #4 from carrot at google dot com 2009-05-31 08:05 ---
(In reply to comment #3)
> I think we have enough passes already and should try to stuff this in cse.c
> and
> fwprop.c. See PR middle-end/33699 for related issues.
>
It looks that patch solved some si
register
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host
--- Comment #1 from carrot at google dot com 2009-06-08 03:23 ---
Created an attachment (id=17962)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17962&action=view)
test case shows the redundant register move
This problem occurs quite frequently if both caller and call
--- Comment #4 from carrot at google dot com 2009-06-09 03:46 ---
Thank you, Steven.
(In reply to comment #3)
> "might be" is such a useless statement.
>
> Carrot, you are aware of the -fdump-rtl-all and -dAP options, I assume? Then
> you should have no tr
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target
--- Comment #1 from carrot at google dot com 2009-06-09 07:35 ---
Created an attachment (id=17969)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17969&action=view)
simple class with empty virtual destructor
Some tree dump result
1. The tree dump of early sta
--- Comment #6 from carrot at google dot com 2009-06-09 13:52 ---
(In reply to comment #5)
> Hmm, I was under the impression that postreload-cse could move instructions
> too, but that was just wishful thinking.
>
I will look into postreload-cse.
--
http://gcc.gnu.org
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
--- Comment #1 from carrot at google dot com 2009-06-11 14:34 ---
Created an attachment (id=17983)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17983&action=view)
test case
The spilling is occurred around the first loop:
push{r4, r5, r6, r7, lr}
sub
--- Comment #3 from carrot at google dot com 2009-06-15 02:26 ---
Created an attachment (id=17998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17998&action=view)
preprocessed test case
A possible code sequence without spilling is:
push{r4, r5, r6,
--- Comment #4 from carrot at google dot com 2009-06-15 02:32 ---
In the source code, only two extra variables next_runs and next_alpha need to
be preserved through the while loop.
But in the gcc generated code, three variables are kept through the first loop.
They are next_alpha
arget
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
--- Comment #1 from carrot at google dot com 2009-06-16 09:11 ---
Created an attachment (id=18005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18005&action=view)
test case
For this function
void foo(int* p)
{
p[0] = 1;
p[1] = 2;
}
gcc generates:
mov r1, #1
mov
--- Comment #7 from carrot at google dot com 2009-06-17 09:30 ---
My command line option is -O2 -Os -mthumb
The compiler didn't run into load_multiple_sequence and
store_multiple_sequence. The peephole rules specified it applies to TARGET_ARM
only. Is there any special reason we d
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla
--- Comment #1 from carrot at google dot com 2009-06-18 07:34 ---
Created an attachment (id=18018)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18018&action=view)
test case
command line option is -O2 -Os -mthumb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from carrot at google dot com 2009-06-20 03:56 ---
Created an attachment (id=18027)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18027&action=view)
test case
The command line options are: -march=armv5te -mthumb -Os
At the end of the function we can see
--- Comment #4 from carrot at google dot com 2009-06-22 08:00 ---
Sorry I didn't make it clear. It is a performance bug, not a code size issue.
If the epilogue is a simple return instruction, the branch to return can be
replaced by the return instruction. So we can execute one
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla
--- Comment #2 from carrot at google dot com 2009-06-23 09:09 ---
Created an attachment (id=18053)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18053&action=view)
test case
Compile the attached code with options -mthumb -march=armv5te -Os, gcc
generates
push
--- Comment #6 from carrot at google dot com 2009-06-30 07:42 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01067.html
--
carrot at google dot com changed:
What|Removed |Added
byte load
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC hos
--- Comment #1 from carrot at google dot com 2009-07-01 06:56 ---
Created an attachment (id=18105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18105&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40603
--- Comment #3 from carrot at google dot com 2009-07-01 10:24 ---
(In reply to comment #2)
> Subject: Re: New: unnecessary conversion from unsigned
> byte load to signed byte load
>
>
> > Unfortunately in thumb mode, loading a signed byte costs more th
: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
--- Comment #1 from carrot at google dot com 2009-07-02 07:39 ---
Created an attachment (id=18120)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18120&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
RMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from carrot at google dot com 2009-07-06 08:16 ---
Created an attachment (id=18140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18140&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
--- Comment #5 from carrot at google dot com 2009-07-07 06:44 ---
Could we do the optimization in function thumb1_expand_prologue? If we find
this opportunity in function thumb1_expand_prologue, we can remove the sp
manipulations from prologue and epilogue. We also should add extra
: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
--- Comment #1 from carrot at google dot com 2009-07-07 09:38 ---
Created an attachment (id=18149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18149&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
ority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
--- Comment #1 from carrot at google dot com 2009-07-08 09:36 ---
Created an attachment (id=18155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18155&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40697
--- Comment #1 from carrot at google dot com 2009-07-09 09:24 ---
Created an attachment (id=18166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18166&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40697
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
--- Comment #1 from carrot at google dot com 2009-07-13 08:58 ---
Created an attachment (id=18183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18183&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
Summary: code size explosion for integer comparison
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at go
--- Comment #1 from carrot at google dot com 2009-07-14 08:41 ---
Created an attachment (id=18191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18191&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40741
--- Comment #4 from carrot at google dot com 2009-07-14 09:14 ---
In TREE level, the two stores are different statements. Only after register
allocation, the two stores get same register and make the load redundant.
try_crossjump_bb tries to find same instruction sequence in all
--- Comment #7 from carrot at google dot com 2009-07-15 08:07 ---
(In reply to comment #6)
> Carrot, can you please try this test case with my patch
> "crossjump_abstract.diff" from Bug 20070 applied?
>
I tried your patch. It did remove the redundant memory loa
te function return values
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet:
--- Comment #1 from carrot at google dot com 2009-07-17 06:56 ---
Created an attachment (id=18212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18212&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40783
oop-invariant
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
--- Comment #1 from carrot at google dot com 2009-07-21 07:15 ---
Created an attachment (id=18234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18234&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
--- Comment #3 from carrot at google dot com 2009-07-21 07:35 ---
Created an attachment (id=18235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18235&action=view)
dump of -fdump-rtl-expand-details
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
instruction
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
--- Comment #1 from carrot at google dot com 2009-07-23 08:38 ---
Created an attachment (id=18241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18241&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835
--- Comment #2 from carrot at google dot com 2009-07-24 02:11 ---
It seems HAVE_cc0 disabled for arm. What's the reason behind it?
A simple method is to add a peephole rule to handle it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835
--- Comment #4 from carrot at google dot com 2009-07-24 07:37 ---
Just as I've figured out HAVE_cc0 is disabled. And cse_condition_code_reg does
nothing for thumb target.
I also found that the conditional branch instructions is always in the same
insn pattern as the previous co
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http
--- Comment #1 from carrot at google dot com 2009-07-29 08:57 ---
Created an attachment (id=18266)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18266&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
--- Comment #1 from carrot at google dot com 2009-08-03 22:55 ---
Created an attachment (id=18294)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18294&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
--- Comment #1 from carrot at google dot com 2009-08-08 00:10 ---
Created an attachment (id=18326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18326&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39989
--- Comment #1 from carrot at google dot com 2009-05-01 06:12 ---
Created an attachment (id=17787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17787&action=view)
sample code showing the optimization opportunity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39989
--- Comment #2 from carrot at google dot com 2009-05-01 06:21 ---
Actually gcc has already implemented this optimization, but it doesn't work for
this case.
Reload pass tries to determine the stack frame, so it needs to check the
push/pop lr optimization opportunity. One o
--- Comment #6 from carrot at google dot com 2009-05-04 02:21 ---
We can compute the maximum possible function length first. If the length is not
large enough far jump is not necessary, and we can do this optimization safely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Bug #: 56993
Summary: power gcc built 416.gamess generates wrong result
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398
Carrot changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398
--- Comment #5 from Carrot 2012-09-11 00:10:45 UTC
---
It's the bug in local dse sub step in dse.c.
66 (insn/f 70 69 71 2 (set (reg/f:SI 7 r7)
67 (plus:SI (reg/f:SI 13 sp)
68 (const_int 0 [0]))) t.ii:24 -1
69 (nil))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398
--- Comment #8 from Carrot 2012-09-12 20:57:33 UTC
---
(In reply to comment #7)
>
> This rings a bell.
>
> Maybe the patch mentioned below needs backporting given Carrot is
> reporting this against the 4.6 branch. What's not clear if this is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54574
Bug #: 54574
Summary: G++ accepts parameters with wrong types in parent
constructor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
--- Comment #4 from carrot at google dot com 2009-08-19 21:55 ---
(In reply to comment #2)
> Why does the basic block reordering pass also not handle this?
>
Basic block reordering is disabled with options -Os.
The basic block reordering algorithm is for performance only, it u
--- Comment #34 from carrot at google dot com 2009-08-27 01:40 ---
There is one optimization that we can do without affecting the ABI and linker
compatibility. The delete destructor(D0) always contains the content of
complete desturctor(D1) followed by a function call to delete. So
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from carrot at google dot com 2009-09-18 07:57 ---
Created an attachment (id=18602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18602&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41396
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41442
--- Comment #1 from carrot at google dot com 2009-09-23 06:49 ---
Created an attachment (id=18634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18634&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41442
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41481
--- Comment #1 from carrot at google dot com 2009-09-27 09:13 ---
Created an attachment (id=18662)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18662&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41481
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41514
--- Comment #1 from carrot at google dot com 2009-09-30 08:25 ---
Created an attachment (id=18671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18671&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41514
--- Comment #3 from carrot at google dot com 2009-10-01 07:37 ---
(In reply to comment #2)
> Where does it come from? (Remember: option -dAP, then look at .s file)
>
The first several instructions and corresponding rtl patterns are:
cmp r0, #63
beq
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41653
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target t
--- Comment #1 from carrot at google dot com 2009-10-14 09:29 ---
Created an attachment (id=18798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18798&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41705
--- Comment #2 from carrot at google dot com 2009-10-15 08:18 ---
arm_size_rtx_costs calls thumb1_rtx_costs for TARGET_THUMB1.
thumb1_rtx_costs is also called by several other functions. Looked at its
implementation briefly, it is actually tuned for speed only. Following are some
--- Comment #3 from carrot at google dot com 2009-10-15 08:25 ---
>
> >
> > Target ARM has conditional execution capability, but thumb actually can't do
> > conditional execution. Do we have any method to let the compiler know this?
>
> Note that this
d at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
--- Comment #1 from carrot at google dot com 2009-10-21 08:50 ---
Created an attachment (id=18850)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18850&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41778
--- Comment #9 from carrot at google dot com 2009-10-23 09:15 ---
(In reply to comment #5)
> This is fixed on trunk by revision 149082:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01067.html
>
The patch 149082 contains two parts: 1. fixed a wrong optimization in
tree-ss
--- Comment #4 from carrot at google dot com 2009-10-27 09:15 ---
A patch http://gcc.gnu.org/viewcvs?view=revision&revision=153584 has been
checked in.
--
carrot at google dot com changed:
What|Removed |A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47133
Summary: code size opportunity for boolean expression
evaluation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47373
Summary: avoid goto table to reduce code size when optimized
for size
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47454
Summary: registers are not allocated according to its preferred
order
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47454
--- Comment #3 from Carrot 2011-01-31 08:48:40 UTC
---
(In reply to comment #2)
> -frename-registers should help for this issue on the ARM.
All of r8 can be renamed to r2, in this case only two of them have been
renamed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47764
Summary: The constant load instruction should be hoisted out of
loop
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Summary: use __aeabi_idivmod to compute quotient and remainder
at the same time
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47764
--- Comment #3 from Carrot 2011-02-21 03:15:45 UTC
---
> Any ideas of how this improvement could be implemented, Carrot?
The root cause of this problem is that arm/thumb store instruction can't
directly store a immediate number to memory, but gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47831
Summary: avoid if-convertion if the conditional instructions
and following conditional branch has the same
condition
Product: gcc
Version: 4.6.0
Status: UNCONFIRME
1 - 100 of 272 matches
Mail list logo
