--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-19 17:33
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-01-05 17:52
---
(In reply to comment #8)
> Seems to work on 4.3.2-1 Debian gnueabi
>
You didn't compile your testcase with -mthumb. Also, that system should be
using unwinding tables for exceptions, rather than bui
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41
---
(In reply to comment #6)
> 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.
>
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-05-05 10:06
---
(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 pretty much it, but...
> B
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-05-16 12:53
---
Subject: Bug 40153
Author: rearnsha
Date: Sat May 16 12:53:22 2009
New Revision: 147613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147613
Log:
PR target/40153
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-05-16 13:28
---
Subject: Bug 40153
Author: rearnsha
Date: Sat May 16 13:28:27 2009
New Revision: 147614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147614
Log:
PR target/40153
--
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 2009-05-16 22:25
---
Subject: Bug 39501
Author: rearnsha
Date: Sat May 16 22:24:59 2009
New Revision: 147623
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147623
Log:
PR target/39501
* arm.md
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-16 23:04
---
Subject: Bug 40153
Author: rearnsha
Date: Sat May 16 23:04:06 2009
New Revision: 147626
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147626
Log:
PR target/40153
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-05-16 23:06
---
(In reply to comment #6)
> Thanks for fixing this. I also submitted a patch yesterday with the same fix
> and a test case also. The bug is fixed but I think we still want the test
> case, right?
Sorr
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-05-21 10:49
---
Another case, compile with -mcpu=arm1136jf-s -mthumb -O2
void f(unsigned a, unsigned b, unsigned c, unsigned d)
{
if (a <= b || c > d)
foo();
else
bar();
}
f:
push{r4, lr}
--- Comment #10 from rearnsha at gcc dot gnu dot org 2009-05-22 14:51
---
The ARM7 does not support unaligned accesses in the way that C programmers
normally expect (even if it doesn't fault them in the MMU then it still won't
fetch what you might expect -- see the CPU m
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-06-03 23:31
---
Subject: Bug 10242
Author: rearnsha
Date: Wed Jun 3 23:31:12 2009
New Revision: 148156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148156
Log:
PR target/10242
* arm.md (ar
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-06-03 23:34
---
fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-06-09 22:06
---
Working on a patch
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-13 12:49
---
Subject: Bug 40327
Author: rearnsha
Date: Sat Jun 13 12:49:25 2009
New Revision: 148452
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148452
Log:
PR target/40327
* arm/constraint
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-06-13 13:04
---
fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
r147852
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target
r147852
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-06-13 23:10
---
For ARM -Os 114 files in CSiBE increase in size (total increase 21449 bytes)
20 files decrease in size (total decreases 1039 bytes); over all increase 20410
bytes)
Worst single increase is from bzip2/compress
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Keywords||missed
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-16 15:50
---
You haven't specified what compilation options you were using.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-06-22 12:37
---
Support for single-instruction return insns has been around a lot longer than
rtl-based epilogues, so there's no need to convert the thumb target to RTL
epilogues as a pre-requisite for fixing this. So
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-22 17:00
---
(In reply to comment #3)
> Is this related to bug 39715?
>
Maybe.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-07-14 14:53
---
The following define_split works for this specific case, but it needs to be
made more generic (handling IOR and HImode variants).
It also needs reworking for big-endian -- that needs (subreg...3).
(define_split
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31
---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-07-22 21:22
---
The transformation to signed char is done very early on (maybe even during
parsing). The 003t.original dump already contains:
if ((signed char) *(p + 8) >= 0)
--
rearnsha at gcc dot gnu dot org chan
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-07-24 14:08
---
(In reply to comment #6)
> In fact even the compare isn't a separate insn:
There's a reason for that.
If you separate compares from uses of the flags then reload may end up
inserting add or mov in
nent: tree-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=40914
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-07-31 10:52
---
Patch proposed here:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01816.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-07-31 21:56
---
Subject: Bug 40914
Author: rearnsha
Date: Fri Jul 31 21:56:28 2009
New Revision: 150319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150319
Log:
PR tree-optimization/40914
* ip
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-07-31 21:57
---
Fixed on trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
t org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41027
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-16 22:14
---
Subject: Bug 24861
Author: rearnsha
Date: Wed Nov 16 22:14:38 2005
New Revision: 107104
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107104
Log:
PR target/24861
* arm.md (split f
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-16 22:31
---
Subject: Bug 24861
Author: rearnsha
Date: Wed Nov 16 22:31:14 2005
New Revision: 107105
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107105
Log:
PR target/24861
* arm.md (split f
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-16 22:34
---
There was a split pattern that was converting a set of a floating point value
into a set of an integer value. This doesn't match anything if the register
being set is a Maverick Co-pro register, and in gener
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-17 20:55
---
The compiler is trying to reload the Maverick register into a VFP register.
But there are no VFP registers on the ep9312!
Testing a fix.
--
rearnsha at gcc dot gnu dot org changed:
What
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-18 17:59
---
Subject: Bug 24914
Author: rearnsha
Date: Fri Nov 18 17:59:37 2005
New Revision: 107187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107187
Log:
PR target/24914
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-18 19:54
---
Subject: Bug 24914
Author: rearnsha
Date: Fri Nov 18 19:54:41 2005
New Revision: 107189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107189
Log:
PR target/24914
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-18 20:05
---
Sometimes when the reload needs to reload an expression that is a subreg
of a wider register, X, into a different class than X it will call
find_valid_class. This routine simply checks whether the class has any
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-21 15:19
---
It seems to me that the problem here is that a 'warning' is too strong here,
particularly with -Werror. We really need a diagnostic that is non-fatal to
the compilation, since there's nothing re
--- Comment #6 from rearnsha at gcc dot gnu dot org 2005-11-21 15:49
---
Subject: Re: -Os should maximize inlining --param
values.
I didn't say the compiler shouldn't say anything, I said it shouldn't be
fatal. Regardless of whether or not you think the lim
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-23 12:12
---
Similar failures on arm:
libbackend.a(timevar.o)(.text+0x1e4): In function `get_time':
/work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to
`__floatunsidf'
libbackend.a(timevar.o)(.
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-23 14:22
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Wed, 2005-11-23 at 14:09, joseph at codesourcery dot com wrote:
> On Wed, 23 Nov 2005, rearn
--- Comment #7 from rearnsha at gcc dot gnu dot org 2005-11-23 14:44
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Wed, 2005-11-23 at 14:28, joseph at codesourcery dot com wrote:
> In that case the obvi
--- Comment #12 from rearnsha at gcc dot gnu dot org 2005-11-25 10:09
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Fri, 2005-11-25 at 02:51, joseph at codesourcery dot com wrote:
> It
> does not addre
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-26 22:44
---
*** This bug has been marked as a duplicate of 16314 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rearnsha at gcc dot gnu dot org 2005-11-26 22:44
---
*** Bug 25044 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-28 16:03
---
Confirmed. This appears to be a bug in noce_try_abs, which is substituting an
abs() expansion into the RTL, but the substitution clobbers a hard register
that is live (the condition code register
--- Comment #21 from rearnsha at gcc dot gnu dot org 2006-01-05 15:06
---
Subject: Bug 24998
Author: rearnsha
Date: Thu Jan 5 15:06:09 2006
New Revision: 109380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109380
Log:
PR middle-end/24998
* arm/
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-01-17 20:22
---
Subject: Bug 11135
Author: rearnsha
Date: Tue Jan 17 20:22:19 2006
New Revision: 109839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109839
Log:
PR target/592
PR middle-e
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-01-17 20:22
---
Subject: Bug 592
Author: rearnsha
Date: Tue Jan 17 20:22:19 2006
New Revision: 109839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109839
Log:
PR target/592
PR middle-e
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-01-17 20:32
---
Closing as WORKSFORME. I didn't have to change anything in the middle-end in
order to fix the ARM back-end.
Maybe the documentation should be updated to reflect this status.
--
rearnsha at gcc dot gn
--- Comment #8 from rearnsha at gcc dot gnu dot org 2006-01-17 20:32
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: *-*-netbsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-08-02 10:38
---
Please provide a fully compilable testcase that demonstrates the bug.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-08-02 12:35
---
> What is the status of PR23624. I see there was a checkin, what do I have to
> do to make use of the change?
You have to convert your code/system to use the EABI version of GCC; or you
have to modif
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-08-29 14:41
---
The only reason for keeping the old predication-based code is that it can
handle an important case that the generic code cannot. Specifically, it can
conditionally skip a call to a function: this is not normally
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41
---
*** This bug has been marked as a duplicate of 16634 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41
---
*** Bug 29004 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rearnsha at gcc dot gnu dot org 2006-10-03 16:25
---
(In reply to comment #7)
> Subject: RE: compiler generates incorrect ARM instructions when using long
> bitfields
>
> Why not? What are the criteria?
Because it isn't a regression.
A regre
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-01-25 17:25
---
--> volatile char buf[512] /*__attribute__ ((aligned (4)))*/;
WHat makes you think this buffer will be word-aligned? One of your
sub-routines creates a variable with 33 bytes, and when inlining happens
ther
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-25 17:35
---
(In reply to comment #6)
> The problem is that the compiler is not either
> 1) automatically aligning the
> buffer so that the program actually works or
It doesn't have to, because the user hasn
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-26 16:46
---
(In reply to comment #6)
> OK. I see now. This seems hard to fix, since it is exposing the current
> implementation of a conversion to bool.
>
No, it's not the 'current implementation',
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-01-26 17:03
---
(In reply to comment #8)
> I meant that the warning is appropriate but
> the message is confusing because it is exposing that when doing
>
> bool x = ~b;
>
> we actually do
>
> b
Since revision r126615:
2007-07-12 Andreas Schwab <[EMAIL PROTECTED]>
* gengtype-lex.l: Allow declarations to be indented.
Bootstrap of gcc on arm-netbsdelf has failed because
build/gengtype /work/rearnsha/gnusrc/gcc/trunk/gcc gtyp-input.list
/work/rearnsha/gnusrc/gcc/tru
Since revision r126615:
2007-07-12 Andreas Schwab <[EMAIL PROTECTED]>
* gengtype-lex.l: Allow declarations to be indented.
Bootstrap of gcc on arm-netbsdelf has failed because
build/gengtype /work/rearnsha/gnusrc/gcc/trunk/gcc gtyp-input.list
/work/rearnsha/gnusrc/gcc/tru
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-08-03 22:35
---
That looks like it solves the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32973
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-16
22:00 ---
Patch fixes untyped returns properly using sfm/lfm as appropriate to avoid
potential type-conversion traps and also fixs returning types larger than a word
in integer registers. Should also work correctly
about 1.5GBytes in size!
/work/rearnsha/gnu/egcs/arm-elf/libjava/testsuite/../../libjava/.libs/libgcj.a(jni.o):
In function `_Jv_JNI_GetAnyMethodID<0u>':
/home/rearnsha/gnusrc/egcs-cross/libjava/jni.cc:730: undefined reference to
`java::lang::StringBuffer::StringBuffer(java::lang::Stri
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-24
13:19 ---
Yes, that's the patch that introduces the problem.
--
What|Removed |
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-24
13:47 ---
This was fixed in gcc-3.3
2002-07-16 Richard Earnshaw <[EMAIL PROTECTED]>
* arm.md (stack_tie): New insn. Use an idiom that the alias code
understands to be a memory c
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-24
14:11 ---
*** This bug has been marked as a duplicate of 20160 ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-24
14:12 ---
*** Bug 20190 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-25
01:49 ---
I've just reproduced this on arm-netbsdelf using gcc-3.3.3. I've managed to
track it down to a miscompilation of pp_hot.c, and the key flag seems to be
-fcse-skip-blocks (-O2 -fno-cse-skip-bl
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-25
01:50 ---
Created an attachment (id=8281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8281&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16152
--
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
||org
Status
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-25
02:04 ---
It's hard to be completely sure what's wrong here, but something *very*
suspcision appears near original source line 2669.
The good code (on ARM) contains:
.L1706:
.LBB453:
ldr r
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-25
14:07 ---
The build fails:
rm -fr .libs/libgcj.lax/libgcjgc_convenience.a
mkdir .libs/libgcj.lax/libgcjgc_convenience.a
(cd .libs/libgcj.lax/libgcjgc_convenience.a &&
/work/rearnsha/gnu/egcs/binutils/ar
Summary: libjava testsuite does not fully support multilibs
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-26
16:34 ---
That patch seems to work, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
ned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf
GCC target triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20542
ned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf
GCC target triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20543
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-03-18
21:24 ---
*** This bug has been marked as a duplicate of 20542 ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-03-18
21:24 ---
*** Bug 20543 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20542
tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20544
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-04-03
14:56 ---
Fixed. I've also done a full audit of the other patterns and fixed similar
cases that I could find.
--
What|Removed |
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-04-16
17:50 ---
(In reply to comment #41)
> Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
> Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline
> to resol
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-02-10 14:36
---
This is not a bug, but a problem with your source code.
In order to understand why, you need to pre-process the code and look at the
output:
...
void *memset_arm9(void *a, int b, int c)
{
return ({ uint8_t
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-02-10 15:21
---
Opinions vary wildly as to which warnings should be on by default, and which
should be part of whatever bundle.
I personally agree that shadowing variables is generally bad practice, but you
then have to be wary
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-03-13 09:38
---
Now believed fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-03-13 09:39
---
Fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 22:53
---
Confirmed. This is a bug in the arith_adjacent_mem pattern that only triggers
when the offset to the memory from the base pointer exceeds the range of a
simple add instruction (ie more than 1024 bytes). In that
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:27
---
I believe this is a bug in the way we expand local reg vars. The manual says:
Local register variables in specific registers do not reserve the
registers, except at the point where they are used as input or
1001 - 1100 of 1817 matches
Mail list logo
