--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-20
17:18 ---
It's the callee's responsibility to save f4...f7 if it wants to use them. So
the problem is in glibc.
Note that gcc 2.95 isn't supported any more, so the most we'd likely do in this
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-22
10:36 ---
The code generated looks correct to me.
The generated assembler that you've give for __cos is clearly saving and
restoring f4-f7.
__cos:
// Saves the integer registers
ca4c: e92
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-25
10:59 ---
Confirmed.
arm_split_constant() already knows how to handle XOR, so it should be just a
matter of copying the model used for andsi3 into the xorsi3 expander.
--
What|Removed
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-25
12:51 ---
Nick patched this on the trunk back in March last year. I've backported the
patch to the branch.
--
What|Removed |
--
What|Removed |Added
Attachment #6629|text/plain |application/x-zip
mime type||
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31
15:55 ---
This is indeed a duplicate of PR16201
*** This bug has been marked as a duplicate of 16201 ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31
15:56 ---
*** Bug 17209 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31
15:59 ---
The problem is the arith_adjacent_mem pattern, which is sometimes expanding to
more than three instructions if the addressed objects are in the stack frame.
Patch in testing.
--
What
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-01
15:08 ---
Fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-11
00:35 ---
CPP_CPU_ARCH_SPEC is no more.
--
What|Removed |Added
Status|NEW
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-11
10:15 ---
The new register allocator (new-ra) has been removed because it was buggy and
there were no plans to fix it. I was using it to show that the initial MOV was
an unrelated issue.
Your code snippet shows
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-11
11:13 ---
I've linked this to the register-allocator meta-bug
--
What|Removed |
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-14
14:06 ---
Not a bug. "bx lr" is the correct instruction to use for returning from
a function on any ARMv4T or later processor.
--
What|Removed
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-09-11 11:19
---
This patch causes regressions on arm-unknown-elf.
Specifically, g++.old-deja/g++.brendan/crash15.C now fails to compile with an ICE.
--
What|Removed |Added
strtold when undeclared
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: build
Severity: critical
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-10-05 19:05
---
Created an attachment (id=7288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7288&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17850
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-10-05 19:21
---
As far as I can see, I think the problem is in configure.ac, where we
automatically assume that newlib has strtold(). This is false AFAICT, newlib
has _strtold, but it doesn't have strtol
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-10-29 15:54
---
Fixed in 4.0. Not intending to fix for 3.4 or earlier, since not a regression.
int f (int x, int y)
{
__asm__("rorw $8, %w0" : "=r"(x): "0" (y) : "cc");
return
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-10-29 16:43
---
I think the key to what has failed here is that the reg-rename pass has missed
the equivalence between start->index and a member of the copied structure.
In pseudo code, the output from the previous p
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: arm-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18274
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18274
: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: critical
Priority: P1
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-11-09
15:09 ---
Created an attachment (id=7504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7504&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18401
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-11-09
15:47 ---
Subject: Re: [4.0.0 Regression] Bootstrap failure on
all ARM targets due to incorrect GCSE
On Tue, 2004-11-09 at 15:09, rearnsha at gcc dot gnu dot org wrote:
> --- Additional Comments F
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-11-23
10:57 ---
I agree that this is a bug, and I think it's been fixed now for gcc-4.x, but I'm
not going to attempt to back-port the fix to the branch, given the possible
work-around outlined below.
The reas
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-11-23
11:03 ---
Subject: Re: EP9312 gcc: undefined reference to __divdf3
On Tue, 2004-11-23 at 06:04, zhangyijin_2008 at 163 dot com wrote:
> I use this function and I test it can run ok. But I don`t know can it run
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-13
09:54 ---
Subject: Re: [4.0.0 Regression] Bootstrap
failure on all ARM targets due to incorrect GCSE
On Sun, 2004-12-12 at 22:10, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments F
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-13
11:44 ---
I don't think that patch is correct. Please try the one from bug 3724:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/linux-elf.h.diff?cvsroot=gcc&r1=1.39&r2=1.40
Also, please a
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-13
15:43 ---
Subject: Re: Profiling optimized code causes segfaults
on ARM due to missing frames
On Mon, 2004-12-13 at 15:28, opensource at artnaseef dot com wrote:
> --- Additional Comments F
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-14
10:33 ---
Agreed.
I suspect it's an oversight.
In gcc-4, this also applies to arm1026*, arm11* and mpcore*.
--
What|Removed |
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-14
14:15 ---
Fixed for 4.0.
Not fixed for 3.4 since it is only a performance tweak and would require a
different patch.
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-14
15:16 ---
As Andrew pointed out, the merge of the eor and the rotate is now done on
mainline in 4.0. The initial redundant MOV is a register allocation artifact.
This particular testcase compiles optimally with
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-14
15:47 ---
Your testcase compiles without error with gcc 3.4 and the development build. On
my pre-release of gcc-3.3.4 I get an unrecognized internal instruction, but no
segmentation fault.
I'd strongly reco
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-15
11:59 ---
use_maximal_pivot() is casting longs to pointers and vice-versa. I strongly
suspect this code is violating C's aliasing rules. The inlining of the function
then opens up more chances for the schedul
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-15
17:17 ---
Compiling the testcase with '-O3 -fPIC' using stock gcc-3.3.2 and gcc-3.3.5
configured for arm-linux produces identical assembly code for gauss_pivot_ker().
So I don't see what
valid-code
Severity: normal
Priority: P3
Component: tree-optimization
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=29801
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-11 00:43
---
Created an attachment (id=12590)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12590&action=view)
reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29801
--- Comment #5 from rearnsha at gcc dot gnu dot org 2006-11-11 23:07
---
Created an attachment (id=12595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12595&action=view)
Further reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29801
--- Comment #2 from rearnsha at gcc dot gnu dot org 2006-11-16 14:16
---
(In reply to comment #0)
> cstore patterns are recognized by genopinit, but
> cause a compiler crash their presence influences code generation.
>
Cstore operations should now work after the patch I
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50
---
The compiler expects 'y' to be correctly aligned because the ABI says that it
can expect this to be so. If you write a program that then provides an
unaligned value, then the behaviour is undefined a
--- Comment #21 from rearnsha at gcc dot gnu dot org 2006-12-04 11:26
---
We can't apply this patch to the 4.1 branch if it would mean users had to use
CVS versions of binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
ure on i386
host
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearns
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-12-13 12:01
---
Created an attachment (id=12793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12793&action=view)
patch for fpa-related floating point problems
--
rearnsha at gcc dot gnu dot org
--- Comment #2 from rearnsha at gcc dot gnu dot org 2006-12-13 12:02
---
Sorry, your proposed patch isn't interworking safe. Can you try the patch I've
attached and let me know if that works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-01-05 10:10
---
A better patch, suggested by Nicolas Pitre is:
@ Result is x + 0.0 = x or 0.0 + y = y.
- teq r4, #0
+ orrsip, r4, xl
moveq xh, yh
moveq xl, yl
RETLDM "r4, r5"
which pe
--- Comment #2 from rearnsha at gcc dot gnu dot org 2007-01-09 10:09
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:08:49 2007
New Revision: 120613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120613
Log:
2007-01-09 Nicolas Pitre <[EMAI
--- Comment #3 from rearnsha at gcc dot gnu dot org 2007-01-09 10:12
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:11:53 2007
New Revision: 120614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120614
Log:
2007-01-09 Nicolas Pitre <[EMAI
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-01-09 10:15
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:14:54 2007
New Revision: 120615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120615
Log:
2007-01-09 Nicolas Pitre <[EMAI
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-01-09 10:17
---
Subject: Bug 30173
Author: rearnsha
Date: Tue Jan 9 10:17:02 2007
New Revision: 120616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120616
Log:
2007-01-09 Nicolas Pitre <[EMAI
--- Comment #6 from rearnsha at gcc dot gnu dot org 2007-01-09 10:20
---
Fixed on trunk and all active release branches
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2007-01-09 11:01
---
It's worse than that. compute_init_costs makes a number of broken assumptions.
Not least of which is that it assumes that gen_... functions in machine
description files will return the pattern of a single
--- Comment #6 from rearnsha at gcc dot gnu dot org 2007-01-09 11:10
---
(In reply to comment #4)
> I see:
> ldrdr2, [r1], #328
>
Which isn't a valid instruction (the offset is too large).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-01-09 15:48
---
gdb's configure uses AC_LIB_HAVE_LINKFLAGS to test for expat. This correctly
sets up the right link flags so that applications will find the shared library.
Is there any reason we can't use that fo
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-09 17:01
---
Confirmed. This is iwmmxt-specific and occurs because the co-processor
load-double-word instructions have a larger offset than LDRD.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-01-22 12:04
---
The reduced testcase also ices on a native i386 build. The problem seems to
crop up somewhere in t81.ivopts pass where a switch statement variable is
transformed from an integral calculation into a cast of a void
401 - 455 of 455 matches
Mail list logo
