--- 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=gcc&view=rev&rev=164441
Log:
2010-09-20 Rafael Carre
PR targ
--- 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 p
--- 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 #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=gcc&view=rev&rev=164437
Log:
2010-09-20 Rafael Carre
PR targ
--- 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=gcc&view=rev&rev=164436
Log:
2010-09-20 Rafael Carre
PR targ
--
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 #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
--- 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
--- 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
--- 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 #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=21694&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
-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 #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
> hand
--- 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
--- 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 acc
--- 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
--- 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 #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-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|Re
--- 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 #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
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 proble
--- 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 #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 #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=21050&action=view)
testcase for introduced regression
compiler options in first line of testcase.
--
http://gcc.
--- 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=21049&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44737
: 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 #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=21048&action=view)
testcase for introduced regression
compiler options in first line of testcase.
--
http://gcc.
--- 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=gcc&view=rev&rev=161
--
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 #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 #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=gcc&view=rev&rev=161040
Log:
PR target/44072
* arm.md (cmpsi
--- 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 #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 #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 #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 requir
--- 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.gn
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed
--- 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 |
--- 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 #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 (.i). Use -save-temps as an extra option when
compiling.
Also, 3.4.6 is no-longer being maintained. Can you
--- 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 #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
--
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: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, hav
--- 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.
-
--- 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 #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 #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=gcc&view=rev&rev=157942
Log:
PR target/43469
--- 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 the
--- 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 #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 #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 #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=20278&action=view)
compressed source for bug
Compiled with
/home/rearnsha/gnu/gcc/trunkd16/./stage1-gcc/xgcc
-B/home/r
--- 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 #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 is
--- 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 exp
--- 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'
--
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 #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
--- 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 wro
--- 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 to
d too 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.gn
--- 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 |
--- 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 #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=gcc&view=rev&rev=157609
Log:
PR target/42321
--- 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 #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
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Priority|P3 |P1
http
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
--- 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
>
>* arm.c (arm_get_frame_offsets): Prefer using r3 for padding a
>push
--- 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 point
--- 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
--- 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, "CO
--
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 #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 #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 #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 #2 from rearnsha at gcc dot gnu dot org 2010-02-17 10:09
---
Pinskia: The M1 is best thought of as a thumb1 only processor, blx is for
jumping across instruction sets.
We need a testcase that demonstrates this problem, without one we can't help.
--
rearnsha at gc
--- 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 #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
--- 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 #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 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=gcc&view=rev&rev=156539
Log:
PR target/42957
--- 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 #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=19813&action=view)
Reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
--- 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 #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
--- 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 #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
> st
--- 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=19803&action=view)
Possible patch
I've been testing the attached patch on ARM (well, thumb) where there'
--
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 #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
--- 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 i
--- 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
>
--- 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.
--- 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 Thum
--- 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
--- 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
1 - 100 of 455 matches
Mail list logo
