--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-04-21 08:27
---
There's no need to pass -mthumb to the assembler. If the compiler has emitted
thumb code it will have inserted a suitable directive into the assembly file
that will cause the assembler to act accord
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-04-24 12:49
---
The testcase doesn't compile. Please attach a full, *compilable*, example of
the program that shows the bug.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-04-24 14:26
---
Confirmed. Also appears on trunk on an arm-elf cross with the flags:
-O3 -funroll-all-loops -fomit-frame-pointer -mno-apcs-frame -finline-functions
-mfpu=vfp -mfloat-abi=softfp -mcpu=arm926ej-s
We are
mal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC build triplet: arm-netbsdelf3.0
GCC host triplet: arm-netbsdelf3.0
GCC target triplet: arm-netbsdelf3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27644
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-05-31 10:12
---
Confirmed on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rearnsha at gcc dot gnu dot org 2006-05-31 10:13
---
Created an attachment (id=11549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11549&action=view)
patch in testing
--
rearnsha at gcc dot gnu dot org changed:
What|
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-05-31 13:41
---
Subject: Bug 27829
Author: rearnsha
Date: Wed May 31 13:41:08 2006
New Revision: 114265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114265
Log:
PR target/27829
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-05-31 13:50
---
patch installed
--
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.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
y
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28215
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-07-01 18:04
---
Created an attachment (id=11787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11787&action=view)
gziped attachment of failing source file (pre-processed)
cc1plus fstream-inst.ii -quiet -dumpbase
--
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 #3 from rearnsha at gcc dot gnu dot org 2008-12-10 14:58
---
Subject: Bug 37668
Author: rearnsha
Date: Wed Dec 10 14:57:18 2008
New Revision: 142647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142647
Log:
Martin Guy <[EMAIL PROTECTED]>
PR target
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-10 15:00
---
Fixed in 4.4.0
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-10 15:10
---
Confirmed. Still present on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-10 15:38
---
Some notes on the failure path:
combine generates the pattern
(insn 1466 1464 1467 192 regeximp.h:320 (set (reg:SI 1002)
(sign_extend:SI (mem/s/j:QI (plus:SI (reg:SI 1000)
(mult:SI
--
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
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
--- Comment #6 from rearnsha at gcc dot gnu dot org 2008-12-16 12:12
---
Fixed on trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-16 16:45
---
I'm unable to reproduce this with any of svn-trunk, gcc-4.1.3 (debian),
gcc-4.3.3 (SVN) or gcc-4.3.2 (debian). The loop essentially reads as
mov r7, #1
mov r6, #0
L5:
...
add r6, r6, #1
cmp r
--- Comment #5 from rearnsha at gcc dot gnu dot org 2008-12-16 12:04
---
Subject: Bug 37436
Author: rearnsha
Date: Tue Dec 16 12:03:41 2008
New Revision: 142778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142778
Log:
PR target/37436
* arm.c (arm_legitimate_inde
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-16 17:12
---
Confirmed. This appears to be a bug in the register-renaming pass, where the
insn
(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-16 17:39
---
Not a bug. You need to write your macro like this:
#define burst_copy(dst,src,len) {\
unsigned t1, t2, t3; \
__asm__ __volatile__ ( \
"1: \n\t" \
"ldmia %1!,{r3-r6} \n\t" \
&qu
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 10:22
---
I'm already testing fixes for this, but my native arm board is very
sl
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-19 17:24
---
Subject: Bug 38578
Author: rearnsha
Date: Fri Dec 19 17:22:58 2008
New Revision: 142837
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142837
Log:
PR bootstrap/38578
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-19 17:25
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
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 2008-12-19 17:32
---
Subject: Bug 38548
Author: rearnsha
Date: Fri Dec 19 17:31:12 2008
New Revision: 142838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142838
Log:
PR target/38548
* arm
--- 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
dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32973
dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32978
--- 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
1 - 100 of 455 matches
Mail list logo
