--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-09-20 15:20
---
Must also be present (even if latent) on 4.5.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot
|dot org
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-09-20 15:25
---
Subject: Bug 45726
Author: rearnsha
Date: Mon Sep 20 15:25:44 2010
New Revision: 164436
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164436
Log:
2010-09-20 Rafael Carre rafael.ca...@gmail.com
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-09-20 15:27
---
Subject: Bug 45726
Author: rearnsha
Date: Mon Sep 20 15:27:13 2010
New Revision: 164437
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164437
Log:
2010-09-20 Rafael Carre rafael.ca...@gmail.com
--- Comment #12 from rearnsha at gcc dot gnu dot org 2010-09-20 15:36
---
Fixed in 4.5.3 and trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rearnsha at gcc dot gnu dot org 2010-09-20 16:13
---
(In reply to comment #13)
Is there something wrong with the first hunk of the patch (arm_movt) ?
Nothing really. I missed that bit.
I think in practice the compiler will never end up matching that pattern
--- Comment #15 from rearnsha at gcc dot gnu dot org 2010-09-20 16:22
---
Subject: Bug 45726
Author: rearnsha
Date: Mon Sep 20 16:21:57 2010
New Revision: 164441
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164441
Log:
2010-09-20 Rafael Carre rafael.ca...@gmail.com
--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-09-16 16:54
---
(In reply to comment #12)
I think it's likely there really is a miscompilation. I've not been able to
get very far trying to set up a native compiler to run on qemu, so it would
help if you could try
--- Comment #19 from rearnsha at gcc dot gnu dot org 2010-09-14 14:05
---
Fixed in all maintained releases.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-09-04 12:24
---
Created an attachment (id=21694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21694action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-09-04 13:40
---
caused by svn+ssh://gcc.gnu.org/svn/gcc/tr...@163802
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from rearnsha at gcc dot gnu dot org 2010-08-12 12:13
---
(In reply to comment #21)
Re. comment #14 I am a bit irritated why this bug survived the 4.4.0
and 4.5.0 release.: Yes, well, ARM maintainers have been in the CC-list for
this bug since the beginning
--- Comment #29 from rearnsha at gcc dot gnu dot org 2010-08-12 12:30
---
(In reply to comment #28)
The problem is that stuff like red-zone presence and size isn't known to the
middle-end, all that stuff is backend private, so I think the right way is to
handle this in the backends
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-07-29 16:29
---
Volatile alone won't prevent re-ordering of non-volatile memory operations.
The volatile keyword only applies to that particular location (requiring the
compiler not to remove it, or change the number of accesses
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-07-28 09:34
---
(In reply to comment #8)
I just realized that this is a packed structure and probably need to look up
the semantics of this in the AAPCS. IIRC the AAPCS states that it doesn't
support packed structures
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-07-24 19:47
---
*** Bug 44999 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-07-24 19:47
---
*** This bug has been marked as a duplicate of 43461 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-07-20 08:55
---
The patch looks OK, but should really be posted to gcc-patches for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-07-20 12:22
---
This code is making completely unreasonable demands on the compiler. You'll
have to recode it to use fewer registers in your ASM block.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-07-17 08:36
---
Not a bug.
The ARM ARM says that the shift must be in the range 1...size.
If you want a vmovl instruction, then write one.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-07-12 17:45
---
Looks to be a valid bug to me. I suspect it's triggered by the
'--enable-maintainer-mode' flag causing -Werror to be used while building
libstdc++.
Paul, is this just a straight prototype problem in the header
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-07-02 21:06
---
*** This bug has been marked as a duplicate of 44787 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-07-02 21:06
---
*** Bug 44788 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44787
--- Comment #12 from rearnsha at gcc dot gnu dot org 2010-06-30 23:42
---
(In reply to comment #9)
Subject: Bug 44694
Author: jakub
Date: Wed Jun 30 06:12:22 2010
New Revision: 161587
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161587
Log:
PR debug/44694
--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-06-30 23:43
---
Created an attachment (id=21048)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21048action=view)
testcase for introduced regression
compiler options in first line of testcase.
--
http://gcc.gnu.org
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: x86_64-none-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44737
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-06-30 23:52
---
Created an attachment (id=21049)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21049action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44737
--- Comment #14 from rearnsha at gcc dot gnu dot org 2010-06-30 23:55
---
Created an attachment (id=21050)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21050action=view)
testcase for introduced regression
compiler options in first line of testcase.
--
http://gcc.gnu.org
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44072
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-06-19 23:00
---
Subject: Bug 44072
Author: rearnsha
Date: Sat Jun 19 23:00:31 2010
New Revision: 161040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161040
Log:
PR target/44072
* arm.md (cmpsi2_addneg
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-06-19 23:18
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-04-24 12:43
---
Not seen this again in a long time, so closing as works for me.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-04-24 14:24
---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01723.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-04-23 12:44
---
EABI configurations will guarantee that 64-bit sized objects will be in
even/odd register pairs. It's best not to use LDRD on the old ABI because in
general the ABI can't guarantee the alignment requirements
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-04-23 21:31
---
Confirmed on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-04-17 17:15
---
I can't see how it would hurt to allow combine to always merge insns that are
known to be consecutive (ie to ignore CLASS_LIKELY_SPILLED_P if
prev_nonenote_insn(consumer) == producer).
--
http://gcc.gnu.org
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-04-14 20:50
---
Before confirming this bug, we need to determine if the following program has
well defined behaviour:
int count_div0 = 0;
int __aeabi_div0()
{
count_div0++;
return 0;
}
int divmod(int a, int b)
{
int q
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-04-14 21:38
---
I think that's enough evidence to confirm.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-04-05 10:02
---
Please supply a full testcase, and explain precisely the problem you are
seeing. I cannot determine from your initial post what problem you are seeing.
--
rearnsha at gcc dot gnu dot org changed
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-04-05 10:15
---
Your source code isn't valid. Naked functions can't just call other C
functions, as they have no prologue/epilogue sequences supplied by the
compiler.
Nevertheless, the compiler shouldn't ICE.
--
rearnsha
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-04-05 13:48
---
Only just come across this report as the 'target' field was not set.
Have you tried a more recent compiler?
I suspect that gcov will need support from your C library in order to work
correctly, have you made
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-04-05 13:53
---
SWP is deprecated in the ARM architecture. It would be a really bad idea to
get gcc to generate that by default as it will break compatibility.
--
rearnsha at gcc dot gnu dot org changed:
What
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-04-05 13:55
---
No, the canonical name for the CPU is correct -- with a dash.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-04-05 13:59
---
We cannot use unpreprocessed C file to replicate bugs -- you need to generate
pre-processed output (filename.i). Use -save-temps as an extra option when
compiling.
Also, 3.4.6 is no-longer being maintained. Can
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-04-02 08:32
---
Subject: Bug 43469
Author: rearnsha
Date: Fri Apr 2 08:32:00 2010
New Revision: 157942
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157942
Log:
PR target/43469
* arm.c
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-04-02 08:36
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-04-01 15:02
---
This is a miscompilation during stage2. The file libcpp/expr.c is miscompiled.
The problem is occurring in num_positive, which ends up generating a shift of a
long long right by 63. The code generated
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-04-01 15:11
---
Insn sequence from postreload dump (order is correct):
(insn 4979 1883 4589 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 276 [0x114
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-04-01 15:32
---
Created an attachment (id=20278)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20278action=view)
compressed source for bug
Compiled with
/home/rearnsha/gnu/gcc/trunkd16/./stage1-gcc/xgcc
-B/home/rearnsha
--- Comment #14 from rearnsha at gcc dot gnu dot org 2010-04-01 19:30
---
It appears that some of the annotations on the DImode reload are incorrect.
The store insn contains
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 276 [0x114])) [87 %sfp+-540 S4 A64])
and the load
--- Comment #15 from rearnsha at gcc dot gnu dot org 2010-04-01 22:04
---
In expr.i.194r.dse2 the DImode load insn contains
(insn 4435 4434 5070 176 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 0 r0)
(mem/c:DI (reg:SI 1 r1) [87 %sfp+-544 S8 A64])) 587
--- Comment #16 from rearnsha at gcc dot gnu dot org 2010-04-01 22:43
---
Hmm, actually the only bit of that pass that runs is a cleanup_cfg with
cross-jumping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
--- Comment #17 from rearnsha at gcc dot gnu dot org 2010-04-01 23:33
---
So what is happening is that the cfg cleanup pass in the CSA pass is merging
the tails of two basic blocks. These blocks both contain an insn that loads a
DI value into R0/R1 from the address in R1. Because
--- Comment #31 from rearnsha at gcc dot gnu dot org 2010-03-31 08:47
---
(In reply to comment #30)
(In reply to comment #29)
Wouldn't it be better to just remove _Unwind_GetRegionStart?
This function is not part of the ARM EABI, and removing it would expose any
(already broken
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-03-26 09:05
---
This is a case where we have a 'variable length array' declaration but where
the variable is really const and well-known at compile time. However, we still
end up with it being 'variably sized' at rtl expand time
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-03-23 13:18
---
This second example clearly has nothing to do with the stated bug report
summary line (there's no m constraint anywhere in the test case), and you
make no attempt to explain what you think is wrong. Please see
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-03-23 13:21
---
You haven't explained what you think is wrong, and you haven't even said what
options you used to generated the code.
If the optimizer is not on the generated code *will* be very poor. That's why
we have
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot
|dot org
early
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
http://gcc.gnu.org
--- Comment #27 from rearnsha at gcc dot gnu dot org 2010-03-22 23:48
---
The ARM ABI permits merging of unwind entries, so this should never default to
opt-in across the entire tool-chain. It might be that when GCC links java
programs that it should pass an option to the linker
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-03-21 15:58
---
testing fix
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #7 from rearnsha at gcc dot gnu dot org 2010-03-21 20:27
---
Subject: Bug 42321
Author: rearnsha
Date: Sun Mar 21 20:27:00 2010
New Revision: 157609
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157609
Log:
PR target/42321
* arm.c
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-03-21 20:30
---
Fixed in trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-03-22 00:51
---
Confirmed. Uxtb is better because for low regs it's only 16-bits.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-03-19 13:27
---
I think the compiler should throw an error if there are any statements in the
naked function other than asm statements. All such asms should be treated as
volatile.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-03-18 17:37
---
Native functions aren't expected to work with a 'C' body.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Priority|P3 |P1
http
--- Comment #15 from rearnsha at gcc dot gnu dot org 2010-03-15 09:16
---
(In reply to comment #14)
The bug was fixed for 4.5 by r148072:
2009-06-02 Richard Earnshaw rearn...@arm.com
* arm.c (arm_get_frame_offsets): Prefer using r3 for padding a
push/pop
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-02-26 14:39
---
I don't think this test case is valid.
Unfortunately, the division function is not completely pure. If a division by
zero occurs, then a handler function may be invoked, which might cause the
contents pointed
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-02-24 11:15
---
I think the real problem here is that shared_const_p thinks that _this_ const
expression can't be shared (though I can't see any reason why it couldn't).
The comment in that function says, CONST can be shared
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-02-24 14:17
---
As suggested, there's no bug in the compiler here, and the error message comes
from the linker. The linker doesn't know what the key function is, so I doubt
it could issue a more accurate diagnostic.
In fact
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-02-18 23:09
---
Please supply pre-processed source that will allow a developer to reproduce the
problem.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-02-19 00:13
---
Hmm, sorry about that, yes, I can confirm the bug as reported in comment #5,
also occurs on trunk.
Do you know if this code compiled on older releases of GCC?
--
rearnsha at gcc dot gnu dot org changed
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-02-19 00:23
---
There are two further targets that define a ..._mark_dllimport function: mcore
and sh (for symbian). The mcore code is the same as arm-pe, but the sh code
does not wrap the symbol inside a MEM operation
--- Comment #7 from rearnsha at gcc dot gnu dot org 2010-02-08 11:26
---
(In reply to comment #6)
Does the ARM backend already support conditional compares?
Yes, but only by manipulating store-flag sequences in the combine pass. That's
a poor-man's implementation and it can lead
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-02-08 16:50
---
Best to do it post RA, so that we can issue the best sequences of insns. I
have some better sequences that could be generated for Thumb2 which would avoid
the need for an IT instruction in many cases
--- Comment #12 from rearnsha at gcc dot gnu dot org 2010-02-06 13:03
---
Yes, this could be fixed in the Thumb back-end by doing it the same way as the
ARM back-end does. However, I still think that is papering over a subtle
problem in the scheduler. This is an insidious problem
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-06 13:12
---
The correct way to write your ASM is to mark it as clobbering memory. That is:
asm volatile (swi #0 :: r (a) : memory);
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-06 13:21
---
Confirmed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-02-06 13:22
---
Created an attachment (id=19813)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19813action=view)
Reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-02-06 14:05
---
Confirmed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-06 14:05
---
Subject: Bug 42957
Author: rearnsha
Date: Sat Feb 6 14:05:27 2010
New Revision: 156539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156539
Log:
PR target/42957
* arm.c
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-02-06 14:05
---
Fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-06 15:23
---
Confirmed. coproc_secondary_reload_class needs to be taught about
reg_equiv_mem (at a minimum).
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-02-04 10:48
---
Created an attachment (id=19803)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803action=view)
Possible patch
I've been testing the attached patch on ARM (well, thumb) where there's a
similar issue. It's
--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-02-04 11:11
---
(In reply to comment #8)
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-01 15:34
---
Fixed in trunk with http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01403.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42671
--- Comment #20 from rearnsha at gcc dot gnu dot org 2010-01-29 10:18
---
(In reply to comment #18)
Function that seems to cost the most time is add_functions(), which is one big
basic block of ~7500 insns (~500 of them call insns).
List scheduling is quadratic in the number
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-01-07 11:45
---
(In reply to comment #2)
1. Yes, the flags used are -mthumb -Os -march=armv5te.
4c: e8bd41f0pop {r4, r5, r6, r7, r8, lr}
50: e12fff1ebx lr
This looks more like a return
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-12-23 15:20
---
Fixed by Paul's patch:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00378.html
Prior to this patch, when debugging the testcase I see:
(gdb)
subfunc (a=492, b=2097148, c=0, d=...) at test.c:9
9
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-12-22 11:16
---
IMO this is a generic bug in the scheduler. The code in sched-deps.c should
note that STACK_POINTER_RTX is being changed and insert a memory barrier that
prevents migration of stack-related memory accesses across
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-12-22 11:58
---
(In reply to comment #6)
If this is a generic bug, why are all dups of this for ARM targets?
Just because it's only been reported against ARM doesn't mean it's not a
generic problem.
--
http://gcc.gnu.org
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-12-22 13:33
---
I've looked at several backends and certainly not all do (sparc for example).
I think they get away with it because the stack pointer is valid in all
addressing constructs -- that's not true for Thumb where SP
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-12-17 11:46
---
Agreed, this is really a target bug.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 447 matches
Mail list logo
