--- Comment #5 from ramana dot r at gmail dot com 2009-03-24 18:53 ---
I can confirm that this is fixed with revision 145038 in the 4.3 branch which
is due to the fix committed here.
http://gcc.gnu.org/viewcvs?view=rev&revision=143942 which is essentially a
backport of the patch
--- Comment #2 from ramana dot r at gmail dot com 2009-03-24 18:34 ---
(In reply to comment #1)
> Created an attachment (id=16728)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728&action=view) [edit]
> A more involved testcase.
>
> This testcase shows the p
--- Comment #4 from ramana dot r at gmail dot com 2009-03-19 16:49 ---
(In reply to comment #3)
> ramana:
> I think you'll find the flags are only set for the 3-way comparisons.
> __aeabi_cmple just returns 0 or 1
> "Use for C <=" in the table means the
--- Comment #2 from ramana dot r at gmail dot com 2009-03-19 16:05 ---
Or get rid of the cmp. The Runtime ABI suggests that the Z,N,C flags are set
for the result of the comparison. If that is true then the second cmp is
unnecessary.
Table 5 section 4.1.2 of the ARM Runtime ABI
--- Comment #1 from ramana dot r at gmail dot com 2009-03-19 15:53 ---
Adding self to CC list -
mainline is also broken. The only difference in mainline is that we generate a
movle instead of movgt.
It should indeed be a moveq instead of a movle.
cheers
Ramana
--
ramana dot r at
--- Comment #2 from ramana dot r at gmail dot com 2009-03-17 14:40 ---
This appears to be fixed on mainline on gcc version 4.4.0 20090317
(experimental) (GCC).
output obtained
42 69 105
42 69 105
--
ramana dot r at gmail dot com changed:
What|Removed
--- Comment #18 from ramana dot r at gmail dot com 2009-03-17 14:27 ---
This commit here
http://gcc.gnu.org/viewcvs?view=rev&revision=143942 which is essentially a
backport of the patch http://gcc.gnu.org/viewcvs?view=rev&revision=137235 . If
this fixes the problem, then the
--- Comment #10 from ramana dot r at gmail dot com 2009-03-17 00:11 ---
This should be a target bug. Also with mainline the testcase empty described in
comment #9 appears fixed.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ramana dot r at gmail dot com 2009-03-17 00:05 ---
Still present with 4.4 mainline as on 20090312 revision. It looks like some
sort of relic left behind with the calculations of the soft frame pointer.
Maybe a peephole will help.
--
ramana dot r at gmail dot com
--- Comment #3 from ramana dot r at gmail dot com 2009-03-15 22:59 ---
(In reply to comment #2)
> Trying to deal with this on the tree level will certainly be the wrong thing.
> A
> target dependent pass should instead try to re-materialize code to generate
> constants f
--- Comment #1 from ramana dot r at gmail dot com 2009-03-15 22:20 ---
I took a look at this for some time on Friday and I found that the
conditional constant propagation pass has pushed down the value
(tree-ssa-ccp.c). This is done by the CCP pass up in the optimization
pipeline
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot r at gmail dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: arm-eabi
--- Comment #4 from ramana dot r at gmail dot com 2009-03-13 12:33 ---
With Mainline today it looks worse -
stmfd sp!, {r4, lr}
mov r4, r0
bl func
add r0, r4, r0
ldrbr3, [r0, #-4] @ zero_extendqisi2
cmp r3, #97
--- Comment #6 from ramana dot r at gmail dot com 2009-03-13 12:28 ---
(In reply to comment #5)
> Can an ARM maintainer please check this bug? Comment #4 suggests this bug is
> fixed, but it needs re-checking now that IRA has been merged.
This is now fixed on mainline even aft
--- Comment #3 from ramana dot r at gmail dot com 2009-03-13 10:54 ---
(In reply to comment #2)
> See Dara's comment.
Occurs even today .
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save el
--- Comment #6 from ramana dot r at gmail dot com 2009-03-12 18:45 ---
With Mainline today gcc produces :
stmfd sp!, {r4, lr}
mov r1, r0, lsr #24
mov r4, r0
mov r0, #8
bl func
mov r1, r4, lsr #16
and r1
--- Comment #1 from ramana dot r at gmail dot com 2009-03-11 23:30 ---
Patch submitted at http://gcc.gnu.org/viewcvs?view=rev&revision=143367
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39378
--- Comment #11 from ramana dot r at gmail dot com 2009-02-08 05:23 ---
(In reply to comment #10)
> This might have been implemented for 4.4 already. Section anchors now have
> been enabled for ARM.
>
4.4 seems to enable this with section anchors turned on. This is the code
--- Comment #8 from ramana dot r at gmail dot com 2009-02-08 05:17 ---
(In reply to comment #7)
> Note you have to do with -fno-inline now on the mainline as the function is
> inlined at -O2.
>
It looks as though this is fixed in 4.3 and mainline today. I checked with 4.1
and
--- Comment #1 from ramana dot r at gmail dot com 2009-02-04 23:38 ---
4.4.0 with revision id 143499 generates the following code with -O3 , -O2 and
-Os . The same code is generated for 4.3.3 as well
sub sp, sp, #8
mov r3, sp
mov r2, #0
--- Comment #7 from ramana dot r at gmail dot com 2009-02-04 21:56 ---
(In reply to comment #6)
This has now been committed as revision 143942 in the 4.3 branch -
Sven, could you check and get back if you still see a problem . If not this bug
can be closed
--
http://gcc.gnu.org
--- Comment #6 from ramana dot r at gmail dot com 2009-02-04 08:34 ---
(In reply to comment #5)
> (In reply to comment #4)
>
> > Looking at the dumps this rtx is generated by the rename registers pass in
> > 4.3.x . In trunk however rename register does not gen
--- Comment #5 from ramana dot r at gmail dot com 2009-02-03 22:06 ---
(In reply to comment #4)
> Looking at the dumps this rtx is generated by the rename registers pass in
> 4.3.x . In trunk however rename register does not generate this rtx and hence
> there is no problem.
--- Comment #4 from ramana dot r at gmail dot com 2009-02-03 21:43 ---
(In reply to comment #2)
> No problem with the trunk, but it's still there in the 4.3 branch.
>
> Here's a test case. Requires -funroll-loops -Os, no problem with any other
> -O,
>
Summary: ICE with an empty function
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot r at gmail dot com
G
xpressions.
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot r at gmail dot com
GCC host triplet: i686-pc-linux-gn
--- Comment #2 from ramana dot r at gmail dot com 2009-01-28 14:49 ---
(In reply to comment #0)
> It doesn't build on SLES10 either, libelf0-0.8.10-36, it ICEs during
> build of libgcc:
>
> ...
> /gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: inter
27 matches
Mail list logo
