--- Comment #10 from spark at gcc dot gnu dot org 2008-11-17 06:13 ---
I agree that the overeager has the worse worst-case bound. I'll happily approve
a patch that drops overeager and leave double-queuing only, provided we have
empirical data over some known programs to show
--- Comment #4 from spark at gcc dot gnu dot org 2008-05-30 18:28 ---
I'm still building the compiler to reproduce the problem.
But can somebody try compiling with --param df-double-queue-threshold-factor=0
and see if it helps ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
--- Comment #4 from spark at gcc dot gnu dot org 2008-01-24 18:16 ---
I don't think this can be implemented in the FE,
at least to be really effective.
The more common cases are not really empty destructor.
E.g. there's inlining involved:
class Foo
{
public:
virtual ~Foo();
};
Foo
.
--
Summary: Dead code in trivial destructors.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spark at gcc dot gnu
--- Comment #2 from spark at gcc dot gnu dot org 2008-01-23 23:23 ---
I understand why it's difficult to delete the code in the middle-end. But this
case seems to be quite common - not the empty body but more common cases are
destructors whose body doesn't need vtable.
--
http
--- Comment #49 from spark at gcc dot gnu dot org 2008-01-17 20:03 ---
Subject: Bug 34400
Author: spark
Date: Thu Jan 17 20:02:56 2008
New Revision: 131608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131608
Log:
2008-01-17 Seongbae Park [EMAIL PROTECTED]
PR rtl
--- Comment #18 from spark at gcc dot gnu dot org 2007-11-30 17:02 ---
Subject: Bug 34171
Author: spark
Date: Fri Nov 30 17:02:43 2007
New Revision: 130539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130539
Log:
gcc/testsuite/ChangeLog:
2007-11-30 Martin Michlmayr [EMAIL
--- Comment #7 from spark at gcc dot gnu dot org 2007-11-21 16:22 ---
(In reply to comment #6)
Subject: Re: [4.3 Regression] Segfault in df_chain_remove_problem
with -O3 on alpha
So it means the basic block has been deleted.
I want to see what happens if I consolidate all
--- Comment #12 from spark at gcc dot gnu dot org 2007-11-21 20:40 ---
At the end of fwprop2 pass in fwprop_done(), we call cleanup_cfg()
and it merges a few blocks, making some bb disappear (in this particular case,
bb index 25), which clears the bit in df_chain
--- Comment #13 from spark at gcc dot gnu dot org 2007-11-21 22:08 ---
The following patch seems to fix the problem:
diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c Wed Nov 21 14:07:15 2007 -0800
@@ -2629,6 +2629,7
--- Comment #15 from spark at gcc dot gnu dot org 2007-11-21 22:43 ---
(In reply to comment #14)
The patch is semi-wrong. The call to emit_insn_after_noloc() should already
set the proper BLOCK_FOR_INSN for every insn. Only doing the
df_insn_change_bb() should be sufficient
--- Comment #16 from spark at gcc dot gnu dot org 2007-11-22 00:30 ---
I'm bootstrapping the following patch. This includes some slight refactoring of
set_block_for_insn/df_insn_change_bb loops within cfgrtl.c.
It's mostly cosmetic change on top of the patch on comment #15.
diff -r
--- Comment #5 from spark at gcc dot gnu dot org 2007-10-11 00:51 ---
What configure option should I use to enable -m1 option support ?
Looks like plain-vanilla configured sh4-elf compiler doesn't support -m1 flag.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33662
--- Comment #2 from spark at gcc dot gnu dot org 2007-08-29 15:23 ---
I suspect this might be due to not updating the rd information after unrolling.
Can you check if
analyze_insns_in_loop() (which calls df_analyze()) is being called just before
the problematic unrolling ?
--
http
--- Comment #24 from spark at gcc dot gnu dot org 2007-07-05 23:44 ---
Subject: Bug 32475
Author: spark
Date: Thu Jul 5 23:44:44 2007
New Revision: 126391
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126391
Log:
2007-07-05 Seongbae Park [EMAIL PROTECTED]
PR rtl
--- Comment #23 from spark at gcc dot gnu dot org 2007-07-03 19:41 ---
This patch:
diff -r 29a7055e69fc gcc/df-scan.c
--- a/gcc/df-scan.c Sun Jun 24 00:16:55 2007 +
+++ b/gcc/df-scan.c Tue Jul 03 12:38:41 2007 -0700
@@ -2763,6 +2763,12 @@ df_def_record_1 (struct
--- Comment #20 from spark at gcc dot gnu dot org 2007-07-02 06:56 ---
We already put stack pointer in the exit block use set always.
However, after epilogue is generated, we see the sp restoration code:
1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
22 [--sp:SI]=bp:SI
23
--- Comment #22 from spark at gcc dot gnu dot org 2007-07-02 17:33 ---
(In reply to comment #21)
I don't think this patch is quite enough.
IIUC, it is still possible (although very unlikely) for stack space to be
required without any MEM_LOAD or MEM_STORE present, and without any
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spark at gcc dot gnu dot org
GCC host triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-29 21:41 ---
Below is the email I sent to Jim Wilson asking for help
with the analysis of the bug.
Hi Jim,
This is an analysis of a correctness bug on ia64,
which root cause has to do with your code.
After dataflow
--- Comment #10 from spark at gcc dot gnu dot org 2007-06-27 18:17 ---
Subject: Bug 32481
Author: spark
Date: Wed Jun 27 18:17:15 2007
New Revision: 126058
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126058
Log:
2007-06-27 Seongbae Park [EMAIL PROTECTED]
PR rtl
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|spark at gcc dot gnu dot org|unassigned at gcc dot gnu
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |zadeck at gcc dot gnu dot
|dot org
--- Comment #30 from spark at gcc dot gnu dot org 2007-06-25 18:13 ---
The following patch will essentially disable the warning
for template instantiations in the anonymous namespace.
Index: gcc/cp/decl2.c
===
--- gcc/cp
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-25 23:13 ---
This patch:
diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:10:32 2007 +
@@ -2849,6 +2849,7 @@ try_combine (rtx i3, rtx i2, rtx i1
--- Comment #7 from spark at gcc dot gnu dot org 2007-06-25 23:25 ---
As David suggested, this might be a slightly better fix:
diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:23:23 2007 +
@@ -2057,6
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-25 05:30 ---
Confirmed.
The following commit:
r125972 | zadeck | 2007-06-23 09:21:43 -0700 (Sat, 23 Jun 2007) | 8 lines
2007-06-23 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32437
*dce.c (deletable_insn_p
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-24 01:05 ---
I think Kenny's last patch for PR32437 fixes this as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-24 02:01 ---
(In reply to comment #5)
Subject: Re: [4.3 Regression] function with asm()
does not setup stack frame
spark at gcc dot gnu dot org wrote:
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-24 01:05
--- Comment #7 from spark at gcc dot gnu dot org 2007-06-18 20:02 ---
Subject: Bug 32339
Author: spark
Date: Mon Jun 18 20:02:33 2007
New Revision: 125825
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825
Log:
gcc/ChangeLog:
2007-06-18 Seongbae Park [EMAIL PROTECTED
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-18 20:49 ---
Subject: Bug 32321
Author: spark
Date: Mon Jun 18 20:49:23 2007
New Revision: 125827
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125827
Log:
2007-06-18 Seongbae Park [EMAIL PROTECTED]
PR rtl
--- Comment #8 from spark at gcc dot gnu dot org 2007-06-19 04:30 ---
(In reply to comment #7)
Subject: Bug 32339
Author: spark
Date: Mon Jun 18 20:02:33 2007
New Revision: 125825
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825
Log:
gcc/ChangeLog:
2007-06-18
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-19 04:38 ---
Fixed.
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from spark at gcc dot gnu dot org 2007-06-15 06:33 ---
Subject: Bug 32339
Author: spark
Date: Fri Jun 15 06:33:24 2007
New Revision: 125736
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125736
Log:
2007-06-14 Seongbae Park [EMAIL PROTECTED]
PR rtl
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-14 14:10 ---
What's the target tripe ? I presume thi sis ia64-unknown-linux ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-14 14:33 ---
Subject: Bug 32341
Author: spark
Date: Thu Jun 14 14:33:21 2007
New Revision: 125715
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125715
Log:
2007-06-14 Rask Ingemann Lambertsen [EMAIL PROTECTED
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-14 17:52 ---
This is a bug in df-scan.c, marking regs unnecessarily as read-write,
which lead to unnecessarily stretched live ranges for regs involved in pre/post
modify insn. I'm working on it.
--
spark at gcc dot gnu dot org
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-14 18:31 ---
diff -r 8522653fd69d gcc/df-scan.c
--- a/gcc/df-scan.c Thu Jun 14 00:17:05 2007 +
+++ b/gcc/df-scan.c Thu Jun 14 11:29:46 2007 -0700
@@ -2982,9 +2982,9 @@ df_uses_record (struct df_collection_rec
case
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-14 19:49 ---
The problem is reproducible also on x86-64.
The following patch seems to fix the ICE.
I'll start a bootstrap/testing.
*** /tmp/gcse.c 2007-06-14 19:46:27.0 +
--- gcc/gcse.c 2007-06-14 19:44:19.0
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-14 21:10 ---
Adding our bugmaster to CC.
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-14 21:12 ---
Kenny, can you take a look ?
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from spark at gcc dot gnu dot org 2007-06-14 03:53 ---
(In reply to comment #10)
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
It's my turn to ask: so what information does hppa_can_use_return_p
need to make the decision ?
We need
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-12 21:43 ---
This patch should fix the bootstrap. I was in the process of running some
regtests when gsyprf11 got reset.
diff -r f78a38a8334b gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cThu May 31 11:43:34 2007 -0700
+++ b
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-12 23:07 ---
(In reply to comment #5)
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
@@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
--- Comment #9 from spark at gcc dot gnu dot org 2007-06-13 03:48 ---
(In reply to comment #8)
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
I think the solution is to remove this check from the insn definition
in pa.md and change the check
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-12 01:14 ---
This is a one-liner but I can't access the machine holding the patch now
(gsyprf11 on HP's test cluster) and I can't remember the line :(
--
spark at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from spark at gcc dot gnu dot org 2007-06-05 22:37 ---
(In reply to comment #24)
any news?
I have (or had, since I seem to have lost it) a patch that will prevent the
invalid warning for the template case, but it will effectively prevent the
valid warning for other
--- Comment #3 from spark at gcc dot gnu dot org 2007-05-22 21:11 ---
(In reply to comment #0)
First I am herewith re-afirming my formal request for Mr. Pinsk to refrain
from
having anything to do with my submissions.
Please refrain from insulting others.
According to my
--- Comment #3 from spark at gcc dot gnu dot org 2007-05-03 00:11 ---
Subject: Bug 31663
Author: spark
Date: Wed May 2 23:11:13 2007
New Revision: 124363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124363
Log:
gcc/ChangeLog:
2007-05-02 Seongbae Park [EMAIL PROTECTED
--- Comment #2 from spark at gcc dot gnu dot org 2007-04-23 16:53 ---
My patch (which is still waiting for a review) should fix this.
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from spark at gcc dot gnu dot org 2007-04-17 17:36 ---
I'm testing the following patch (which fixes the ICE).
It turned out to be a latent bug in the warning code not handling pointer types
correctly.
Index: cp/decl2.c
--- Comment #13 from spark at gcc dot gnu dot org 2007-04-16 17:49 ---
Subject: Bug 29365
Author: spark
Date: Mon Apr 16 17:49:02 2007
New Revision: 123879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123879
Log:
gcc/ChangeLog:
2007-04-16 Seongbae Park [EMAIL PROTECTED
--- Comment #8 from spark at gcc dot gnu dot org 2007-04-03 23:50 ---
The following patch addresses the problem.
Do we want to add a flag to control this ?
--- a/gcc/cp/decl2.cMon Apr 02 15:48:00 2007 +
+++ b/gcc/cp/decl2.cTue Apr 03 22:45:49 2007 +
@@ -1860,9 +1860,13
--- Comment #10 from spark at gcc dot gnu dot org 2007-04-04 00:18 ---
(In reply to comment #9)
(In reply to comment #8)
The following patch addresses the problem.
Do we want to add a flag to control this ?
Except if you look at the file name, you could get a case where you
--- Comment #33 from spark at gcc dot gnu dot org 2007-03-26 16:54 ---
(In reply to comment #31)
Here is a new patch. I need someone to test on SPEC. It is very simple.
Index: transfer.c
===
*** transfer.c
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-27 00:56 ---
# cat -n t.c
1 typedef __attribute__((deprecated)) int foo;
2 typedef
3 struct
4 __attribute__((deprecated))
5 bar1
6 {
7foo baz;
8 }
9 bop1
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-23 05:00 ---
Follow up on Joseph's analysis:
The problematic STRIP_SIGN_NOPS() call is from fold_unary()
which is called from try_combine_conversion() in tree-ssa-pre.c.
STRIP_SIGN_NOPS() is called with the expression
--- Comment #17 from spark at gcc dot gnu dot org 2007-03-20 15:42 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 15:42:37 2007
New Revision: 123087
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123087
Log:
2007-03-19 Seongbae Park [EMAIL PROTECTED]
PR tree
--- Comment #18 from spark at gcc dot gnu dot org 2007-03-20 16:44 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 16:44:00 2007
New Revision: 123089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123089
Log:
2007-03-20 Seongbae Park [EMAIL PROTECTED]
PR tree
--- Comment #19 from spark at gcc dot gnu dot org 2007-03-20 16:45 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 16:44:54 2007
New Revision: 123090
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123090
Log:
2007-03-20 Seongbae Park [EMAIL PROTECTED]
PR tree
--- Comment #14 from spark at gcc dot gnu dot org 2007-03-20 04:45 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 04:45:14 2007
New Revision: 123083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123083
Log:
2007-03-19 Seongbae Park [EMAIL PROTECTED]
PR tree
--- Comment #15 from spark at gcc dot gnu dot org 2007-03-20 04:50 ---
Fixed in 4.1, 4.2 and 4.3
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from spark at gcc dot gnu dot org 2007-03-15 23:48 ---
Subject: Bug 30590
Author: spark
Date: Thu Mar 15 23:48:13 2007
New Revision: 122964
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122964
Log:
2007-03-15 Seongbae Park [EMAIL PROTECTED]
PR tree
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-13 16:15 ---
tree-nrv code doesn't see:
bb 2:
retval.type = 0;
because it only looks at GIMPLE_MODIFY with the operand 0 as the return value.
In this case, there's GIMPLE_MODIFY of the component of the return value
hence
--- Comment #9 from spark at gcc dot gnu dot org 2007-03-13 18:29 ---
How does this one look ? If it looks reasonable, I'll start the testing with
the mainline.
Index: tree-nrv.c
===
--- tree-nrv.c (revision 122871
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org
|dot org
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-13 22:57 ---
This is somewhat complicated.
The extra type cast causes
different code paths to be taken.
In particular, in finish_call_expr() in cp/semantics.c:
if (processing_template_decl
--- Comment #8 from spark at gcc dot gnu dot org 2007-03-13 23:43 ---
I believe all issues are fixed at this point,
except for the extra error message of can't find a register.
But since it's accompanied with a proper error message,
I don't think this is a problem anymore.
$gcc -fPIC
--- Comment #11 from spark at gcc dot gnu dot org 2007-03-14 05:48 ---
Subject: Bug 30590
Author: spark
Date: Wed Mar 14 05:48:35 2007
New Revision: 122909
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122909
Log:
2007-03-13 Seongbae Park [EMAIL PROTECTED]
PR tree
--- Comment #4 from spark at gcc dot gnu dot org 2007-03-12 23:46 ---
This little patch below seems to get around the problem,
though I'm not really sure this is sufficient or not.
Index: tree-cfg.c
===
--- tree-cfg.c
--- Comment #7 from spark at gcc dot gnu dot org 2007-02-06 19:43 ---
Subject: Bug 28686
Author: spark
Date: Tue Feb 6 19:43:41 2007
New Revision: 121663
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121663
Log:
2007-02-06 Seongbae Park [EMAIL PROTECTED]
PR inline-asm
--- Comment #5 from spark at gcc dot gnu dot org 2007-02-01 17:47 ---
-O1 error problem is due to constant assignment of var.
If you replace:
long var = 42;
with something like:
long var = func();
It compiles without an error (though it still has the #3 problem
of using %ebp even
--- Comment #6 from spark at gcc dot gnu dot org 2007-02-01 23:15 ---
Subject: Bug 28686
Author: spark
Date: Thu Feb 1 23:15:13 2007
New Revision: 121477
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121477
Log:
2007-2-01 Seongbae Park [EMAIL PROTECTED]
PR inline-asm
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
CC|seongbae dot park at gmail |
|dot com |
AssignedTo
--- Comment #4 from spark at gcc dot gnu dot org 2007-01-31 00:28 ---
Looks like eliminable_regset is not cleared per every invocation of
global_alloc, making stale bits from the compilation of previous function hang
around - hence a presence of a previous function makes difference
77 matches
Mail list logo
