--- 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=16728action=view) [edit]
A more involved testcase.
This testcase shows the preserving behaviour
--- 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=revrevision=143942 which is essentially a
backport of the patch http
--- 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
--- 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 #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 C language, not the carry flag.
If you
--- Comment #18 from ramana dot r at gmail dot com 2009-03-17 14:27 ---
This commit here
http://gcc.gnu.org/viewcvs?view=revrevision=143942 which is essentially a
backport of the patch http://gcc.gnu.org/viewcvs?view=revrevision=137235 . If
this fixes the problem, then the bug can
--- 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 #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 #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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
--- 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
--- 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 eliminated
--- 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 after IRA
--- 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-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=revrevision=143367
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39378
--- 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 saw
--- 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
generated
--- 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 generate this rtx and
hence
--- 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 #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 #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,
or without -funroll-loops
--- 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. It could
ReportedBy: ramana dot r at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39049
ReportedBy: ramana dot r at gmail dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39016
--- 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: internal
compiler error
26 matches
Mail list logo
