--- Additional Comments From rth at gcc dot gnu dot org 2005-09-02 00:28
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-02 21:39
---
Actually, BACKTRACESPEC does make it into libgcj.spec via substitution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-02 22:08
---
I'm sure that the patches listed in comments #6 and #7 are bogus.
But we've had problems before with unwinding with -mno-accumulate-outgoing-args
(implied by -mtune=i486, implied by i486-linux), p
tatus: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gn
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-02 22:54
---
Subject: Re: [4.1 Regression] ICE: "missing REG_EH_REGION note in the end of
bb"
On Fri, Sep 02, 2005 at 10:31:21PM -, kkojima at gcc dot gnu dot org wrote:
> There is yet another "mis
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-03 00:27
---
The true problem is in optimize_mode_switching. The code about line 605
that inserts code around (but not on) abnormal edges, is incorrect. This
is immediately obvious in this case because the emit_insn_after
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-07 01:55
---
You could also disable the test for lp64, if you felt that better.
But then you should document that the various isa extension options
are non-functional.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:35
---
>From the log, this was a gdb bug.
--
What|Removed |Added
Status|UNCONFIR
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:42
---
A more severe example is gdb.base/call-ar-st.c wherein the local static variable
"double_array" is not put to the debug info at all. Not even its name as in the
example here.
--
http://gcc.gnu.or
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-09 01:08
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-09 19:08
---
Well it does with cvs head gdb on linux, both stabs and dwarf2. If you'll
verify that you see something akin to
.stabs "z:(0,7)",128,0,0,-4
.stabs "w:(0,9)",128
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-09 21:06
---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-09 21:07
---
Oh, and that's a WONTFIX for 3.4, in case anyone's interested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-10 21:13
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
: rth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23941
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-19 17:10
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-29 16:31
---
Subject: Re: too liberal operator lookup
On Thu, Sep 29, 2005 at 02:28:03PM -, mmitchel at gcc dot gnu dot org wrote:
> Also, please code this using a loop:
>
> for (i = 0; i < 2; ++i) {
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-30 19:52
---
Subject: Re: [4.0 Regression] Optimizes away FPU control word store
On Fri, Sep 30, 2005 at 02:10:48PM -, bonzini at gcc dot gnu dot org wrote:
> rth, should this be fixed in the front-end or in
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #5 from rth at gcc dot gnu dot org 2005-10-03 22:05 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from rth at gcc dot gnu dot org 2005-10-05 18:23 ---
"Fixed".
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #23 from rth at gcc dot gnu dot org 2005-10-05 21:16 ---
I'm surprised this is considered tricky. Seems to me you just stuff the
attribute away in the parse tree somewhere and pretend we've just read it
in during template instantiation. That's what we do
--- Comment #7 from rth at gcc dot gnu dot org 2005-10-06 00:08 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from rth at gcc dot gnu dot org 2005-10-06 00:53 ---
Created an attachment (id=9898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9898&action=view)
maybe fix mode switching vs abnormal edges
Try this patch on top of the other.
--
http://gcc.gnu.org/b
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
--- Comment #11 from rth at gcc dot gnu dot org 2005-10-06 03:17 ---
And regression testing? Anything that actually excersises the fpscr switching
code...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #14 from rth at gcc dot gnu dot org 2005-10-06 08:45 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #14 from rth at gcc dot gnu dot org 2005-10-06 17:17 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #3 from rth at gcc dot gnu dot org 2005-10-06 17:49 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #10 from rth at gcc dot gnu dot org 2005-10-06 19:42 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rth at gcc dot gnu dot org 2005-10-06 22:14 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rth at gcc dot gnu dot org 2005-10-07 21:03 ---
Steven's complaining about the solution...
--
rth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from rth at gcc dot gnu dot org 2005-10-07 21:04 ---
... so it's his. Revert the patch and do what you like.
--
rth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from rth at gcc dot gnu dot org 2005-10-10 21:56 ---
Created an attachment (id=9954)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9954&action=view)
proposed patch
Try this. Zdenek, as I read things, freeing the estimates should be safe,
and are recomp
--- Comment #5 from rth at gcc dot gnu dot org 2005-10-11 19:21 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #25 from rth at gcc dot gnu dot org 2005-10-11 19:24 ---
I don't think we can reasonably attack this for 4.1. This is something
that should be done during a stage 1.
--
rth at gcc dot gnu dot org changed:
What|Removed |
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #6 from rth at gcc dot gnu dot org 2005-10-11 23:38 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #11 from rth at gcc dot gnu dot org 2005-10-12 16:35 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rth at gcc dot gnu dot org 2005-10-12 17:01 ---
Not fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #9 from rth at gcc dot gnu dot org 2005-10-12 23:39 ---
Fixed, again
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #14 from rth at gcc dot gnu dot org 2005-10-14 21:40 ---
Open to...
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #15 from rth at gcc dot gnu dot org 2005-10-14 21:40 ---
... work on a better solution.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rth at gcc dot gnu dot org 2005-10-16 02:24 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
ary: Old-style asms don't clobber memory
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth
--- Comment #3 from rth at gcc dot gnu dot org 2005-10-17 21:02 ---
If we decided this was not-a-bug, then there's a bug in __sync_synchronize,
as that uses asm("") if there's no target fallback.
But personally I think this is a documentation bug. We should c
--- Comment #7 from rth at gcc dot gnu dot org 2005-10-17 23:11 ---
You seem to be under the incorrect impression that gcc invented old-style asms.
I'm confirming the bug.
--
rth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #10 from rth at gcc dot gnu dot org 2005-10-17 23:23 ---
Are you being intentionally obtuse, Andrew?
How many different ways do I have to say that GCC did not invent the asm?
It exists and has existed in *many* C compilers, many of which pre-date GCC.
THERE IS A TRADITIONAL
--- Comment #1 from rth at gcc dot gnu dot org 2005-10-18 09:48 ---
So, when was your last update? AFAIK this was fixed 3 days ago.
I've just now tested again on amd64-linux and see
MAIN__:
.LFB2:
movl$equiv.0.898, %eax
movl$equiv.0.898+33554432, %ed
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #5 from rth at gcc dot gnu dot org 2005-10-19 09:03 ---
The pr24428-2.c test hand-folds the loop to pointer arithmetic (done on
mainline by tree-level loop changes), which exposes the problem in 4.0.
So backported and applied.
--
rth at gcc dot gnu dot org changed
--- Comment #4 from rth at gcc dot gnu dot org 2005-10-20 08:35 ---
Well, the ideal fix is to make use of the dwarf3 DW_OP_call_frame_cfa
directive, and let the debugger get the CFA information from the ia64
unwind info. Similarly for the arm eabi unwind info.
I'm not sure what a
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #3 from rth at gcc dot gnu dot org 2005-10-21 22:10 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rth at gcc dot gnu dot org 2005-10-21 23:44 ---
Fixed as part of other goto and label cleanups.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #12 from rth at gcc dot gnu dot org 2005-11-01 07:35 ---
Frankly, this smells like a plain old-fashioned reload bug to me.
There's no reason this insn couldn't have been rendered as
movl %esi,%eax
movbl %al,%eax
Investigating further to see how nasty i
--- Comment #13 from rth at gcc dot gnu dot org 2005-11-02 02:12 ---
Subject: Bug 21518
Author: rth
Date: Wed Nov 2 02:12:32 2005
New Revision: 106373
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106373
Log:
PR 21518
* loop.c (scan_loop): Do not p
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #14 from rth at gcc dot gnu dot org 2005-11-02 06:31 ---
Subject: Bug 21518
Author: rth
Date: Wed Nov 2 06:31:48 2005
New Revision: 106378
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106378
Log:
PR 21518
* loop.c (scan_loop): Do not p
--- Comment #15 from rth at gcc dot gnu dot org 2005-11-02 06:32 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #21 from rth at gcc dot gnu dot org 2005-11-02 06:39 ---
I'm no longer actively working on this.
--
rth at gcc dot gnu dot org changed:
What|Removed |
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #10 from rth at gcc dot gnu dot org 2005-11-02 07:43 ---
Created an attachment (id=10112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10112&action=view)
proposed patch
The root problem is that get_aligned_mem and aligned_memory_operand
didn't match up.
--- Comment #4 from rth at gcc dot gnu dot org 2005-11-02 08:06 ---
Still present in 4.1.
As a guess, we're creating a BLKmode register (because alignof(struct s1)
is less than alignof(HImode)), and assign_parm_setup_block forces the data
into the stack. It's possible t
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-02 08:09 ---
And there is nothing Alpha specific about this. Any target which passes
structures in registers can show it. For instance, ia64:
f1:
.prologue
.body
.mmi
st2 [r12] = r32
nop 0
--- Comment #11 from rth at gcc dot gnu dot org 2005-11-02 18:20 ---
Subject: Bug 24178
Author: rth
Date: Wed Nov 2 18:20:07 2005
New Revision: 106388
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106388
Log:
PR target/24178
* config/alpha
--- Comment #13 from rth at gcc dot gnu dot org 2005-11-02 21:44 ---
Subject: Bug 22429
Author: rth
Date: Wed Nov 2 21:44:17 2005
New Revision: 106400
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106400
Log:
PR 22429
* fold-const.c (build_range_che
--- Comment #14 from rth at gcc dot gnu dot org 2005-11-02 21:47 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from rth at gcc dot gnu dot org 2005-11-03 00:33 ---
Subject: Bug 24178
Author: rth
Date: Thu Nov 3 00:33:09 2005
New Revision: 106417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106417
Log:
PR target/24178
* config/alpha
--- Comment #14 from rth at gcc dot gnu dot org 2005-11-03 00:34 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-03 01:40 ---
Subject: Bug 9350
Author: rth
Date: Thu Nov 3 01:40:33 2005
New Revision: 106420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106420
Log:
PR target/9350
PR target/24374
* dwa
--- Comment #7 from rth at gcc dot gnu dot org 2005-11-03 01:40 ---
Subject: Bug 24374
Author: rth
Date: Thu Nov 3 01:40:33 2005
New Revision: 106420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106420
Log:
PR target/9350
PR target/24374
* dwa
--- Comment #8 from rth at gcc dot gnu dot org 2005-11-03 01:42 ---
Fixed for mainline. I have no particular need to see this backported to 4.0.
Any change there should be limited to ix86_function_ok_for_sibcall.
--
rth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rth at gcc dot gnu dot org 2005-11-03 01:43 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rth at gcc dot gnu dot org 2005-11-03 02:18 ---
Hum. I suppose we could just mark the variable TREE_NO_WARNING. Our
only other option is to pass by reference, and that would suppress any
legitimate warnings as well.
--
rth at gcc dot gnu dot org changed
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #4 from rth at gcc dot gnu dot org 2010-03-16 23:02 ---
Subject: Bug 43365
Author: rth
Date: Tue Mar 16 23:02:35 2010
New Revision: 157499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157499
Log:
PR middle-end/43365
* tree-eh.c (replace_go
--- Comment #4 from rth at gcc dot gnu dot org 2010-04-07 15:45 ---
My best guess is that this optimization should be done late.
For instance, in the machine-dependant reorg pass. I don't
see any place to hook this earlier.
The problem is that reload should be able to "spil
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-07-20 00:11
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-07-20 05:27
---
Thanks for the reduction; I see the problem clearly now. For the record,
b$real_193 = CR.53_187;
b$imag_194 = CI.54_188;
c$real_195 = b$real_193;
c$imag_196 = b$imag_194;
we had a ring of copies to
--- Additional Comments From rth at gcc dot gnu dot org 2005-07-25 18:18
---
Whatever you might think, this is not my bug.
This is the C++ front end calling ggc_collect in the middle of parsing a
function. I can't tell whether or not there is a ggc_push_context missing
when we
301 - 400 of 974 matches
Mail list logo
