--- Comment #3 from steven at gcc dot gnu dot org 2007-03-10 12:20 ---
I can still not reproduce this.
[EMAIL PROTECTED]:~/src/build/gcc$ ./g++ -B. -O2 -ftracer -v t.C --param
ggc-min-expand=100 --param ggc-min-heapsize=131072 -c
Reading specs from ./specs
Target: i486-linux-gnu
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-11 10:14 ---
*** Bug 31116 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-11 10:14 ---
Same problem as PR31127.
*** This bug has been marked as a duplicate of 31127 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|31116 |
Status|UNCONFIRMED |NEW
Ever
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-11 11:01 ---
Created an attachment (id=13188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13188&action=view)
suggestion for what a fix may look like
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
--- Comment #76 from steven at gcc dot gnu dot org 2007-03-12 23:24 ---
Joost,
You wrote in comment #75:
"One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments),"
This is a complaint I've heard before. I wonder if you have any sugg
--- Comment #1 from steven at gcc dot gnu dot org 2007-03-13 18:55 ---
I believe this is the proper fix:
Index: cfglayout.c
===
--- cfglayout.c (revision 122858)
+++ cfglayout.c (working copy)
@@ -697,7 +697,6
--- Comment #5 from steven at gcc dot gnu dot org 2007-03-15 16:45 ---
Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it
certain that the patch for r122821 caused the bootstrap comparison failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-26 22:13 ---
Re. comment #5
Andrew, stop spreading nonsense. Other compilers do take register pressure
into account. In fact, they do so much better than GCC usually does. (In GCC
you can't do it well because instruc
--- Comment #10 from steven at gcc dot gnu dot org 2007-03-26 22:33 ---
Just a small heuristics problem. This could be fixed by giving insns to move
with comp_cost - size_cost == 0 in gain_for_invariant a small gain anyway. Or
maybe comp_cost should overrule size_cost.
Just as a
--- Comment #11 from steven at gcc dot gnu dot org 2007-03-26 22:36 ---
And of course the hack doesn't actually work :-) But it's still just a
heuristics tweak what we need here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #12 from steven at gcc dot gnu dot org 2007-03-26 22:43 ---
Zdenek, what is the size heuristic for anyway? For powerpc, the current
heuristic tells the compiler not to move any simple moves:
1) An invariant with a gain of 0 will not be moved.
2) gain = comp_cost
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-29 13:00 ---
No dependent bugs left.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-29 13:01 ---
Lack of activity alone is reason enough to close this.
On top of that, this meta-bug has no dependent bugs left. In fact it appears
to never have had any.
--
steven at gcc dot gnu dot org changed
--- Comment #26 from steven at gcc dot gnu dot org 2007-03-29 13:18 ---
I have looked at the various test cases in this PR, and all of them work for
me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-29 13:29 ---
For the original test case, our current output before expand (i.e. the
final_cleanup dump) on hosts where sizeof(long)==sizeof(int) is this:
;; Function convertToMinutes (convertToMinutes)
convertToMinutes
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-30 15:21 ---
Looks like the kind of bug that cfglayout mode might introduce.
Will investigate...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-30 15:21 ---
Looks like the kind of bug that cfglayout mode might introduce.
Will investigate...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-30 15:22 ---
Which target is this, BTW?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2007-03-30 15:21:40 |2007-03-30
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-30 21:05 ---
TREE_COMPLEXITY is history
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2007-03-30 21:16 ---
At the end of loop2, the tryagain label is turned into a deleted label note.
This happens because the label has zero uses left in cfglayout. There are only
unconditional jumps to it, unconditional jumps are removed
--- Comment #7 from steven at gcc dot gnu dot org 2007-03-30 23:29 ---
Index: cfgcleanup.c
===
--- cfgcleanup.c(revision 123362)
+++ cfgcleanup.c(working copy)
@@ -2034,6 +2034,8 @@ try_optimize_cfg (int
--- Comment #9 from steven at gcc dot gnu dot org 2007-04-01 19:26 ---
Subject: Bug 31391
Author: steven
Date: Sun Apr 1 19:26:00 2007
New Revision: 123406
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123406
Log:
PR rtl-optimization/31391
* cfgc
--- Comment #10 from steven at gcc dot gnu dot org 2007-04-02 06:41 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from steven at gcc dot gnu dot org 2007-04-03 07:17 ---
Need to reverse the loop counter here.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-03 16:34 ---
Re. comment #4:
Answer: Go ahead and implement it in loop.c.
If you want to fix it only for GCC 4.1, that is. There is no loop.c in GCC 4.2
and later.
So does it make sense? Depends on what you want to achieve
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-03 16:36 ---
Maybe you can show the assembly output you're expecting?
tree level if-conversion for the vectorizer _should_ be able to recognize this
case. It may be that it's just not set up to deal with x86* insns of
--- Comment #13 from steven at gcc dot gnu dot org 2007-04-03 16:40 ---
So this may be a non-monotonous dataflow problem...?
Do we have the dataflow equations of the var-tracking problem somewhere? It'd
be interesting to check them against the actual implementation.
--
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-04 12:12 ---
I want to understand this better, so I'll investigate this.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-04 12:17 ---
Richi, Honza, is anyone looking at this problem?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-04-04 12:19 ---
Still see this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-04 12:47 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-05 12:54 ---
Can we compute the displacement reliable enough to say that it is smaller than
some other number (e.g. 64)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29793
--- Comment #6 from steven at gcc dot gnu dot org 2007-04-05 22:01 ---
The tree dump for the original test case now looks like this for me:
;; Function foo (foo)
foo (p)
{
:
return (unsigned int) ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0);
}
;; Function bar (ba
--- Comment #12 from steven at gcc dot gnu dot org 2007-04-09 17:51 ---
Yay to making it an ICE instead of a warning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-10 16:38 ---
Inlining decisions are based on heuristics. What works for one target may not
work quite as well for another. In this case, it seems that for AVR the
heuristics are not the best. You can tune the heuristics for this
--- Comment #7 from steven at gcc dot gnu dot org 2007-04-11 14:35 ---
Watch Bug 14495 while you're at it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-11 22:40 ---
investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #17 from steven at gcc dot gnu dot org 2007-04-13 22:39 ---
Manuel has a good patch for this. I don't know what's holding it up.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-13 22:41 ---
I've tried a couple of different ways to use branch predictions for
partitioning, but it never leads to meaningful results. Either everything is
hot or everything is cold. I don't know what else to do
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-13 22:43 ---
Transient bug? I can't reproduce it with any of the mentioned revisions.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-14 23:55 ---
Randon register allocation fluctuations.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-04-16 19:40 ---
This is not yet fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-17 07:12 ---
To the reporter:
Even though this is already (correctly) closed as INVALID, please let us know
if your code does compile and run correctly if you compile with the suggested
extra command line option, -ffixed-line
--- Comment #6 from steven at gcc dot gnu dot org 2007-04-17 22:09 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #16 from steven at gcc dot gnu dot org 2007-04-17 22:13 ---
Fixeth on ze trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from steven at gcc dot gnu dot org 2007-04-20 21:58 ---
It is my intention to fix see.c to work on x86* hardware, so I'm taking this
bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #21 from steven at gcc dot gnu dot org 2007-04-20 22:10 ---
Collection of important related links:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00766.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437#c5
--
steven at gcc dot gnu dot org changed:
What
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-22 10:10 ---
Waiting for feedback, so bug is WAITING.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-24 20:31 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01609.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2007-07-25 19:43 ---
This may actually have been fixed by my cfglayout work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234
--- Comment #3 from steven at gcc dot gnu dot org 2007-07-25 19:44 ---
This may be fixed now by my cfglayout work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18146
--- Comment #10 from steven at gcc dot gnu dot org 2007-08-07 21:01 ---
Never confirmed, and reported says the bug seems to be fixed.
If the bug is still there, please re-open this PR.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-08-14 21:34 ---
r127273 is this patch: http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00165.html
My initial reaction was, "What happens to the REG_RETVAL note, if the insn with
the REG_LIBCALL note?" I don't know what h
--- Comment #1 from steven at gcc dot gnu dot org 2007-08-14 21:40 ---
No, the pointer comparison here is correct. Using rtx_equal_p here would result
in finding non-shared address rtx'en as false positives.
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from steven at gcc dot gnu dot org 2007-08-16 14:35 ---
Starting program: /home/steven/devel/build-test/gcc/cc1 -g -O2 -fPIC -Dpa64=1
-mlong-calls -fkeep-inline-functions libgcc2.i
__multc3
Analyzing compilation unit
Performing interprocedural optimizations
--- Comment #6 from steven at gcc dot gnu dot org 2007-08-16 14:54 ---
Created an attachment (id=14064)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14064&action=view)
remove nested libcall handling from gcse.c
This is the *only* place in the entire compiler where GCC
--- Comment #7 from steven at gcc dot gnu dot org 2007-08-16 15:05 ---
Fix for the bug:
Index: lower-subreg.c
===
--- lower-subreg.c (revision 127558)
+++ lower-subreg.c (working copy)
@@ -897,7 +897,7
--- Comment #3 from steven at gcc dot gnu dot org 2007-08-18 14:13 ---
This is really a case of missed code hoisting. There are several ways to
resolve this bug.
The first thing I would do, is to experiment with the existing code hoisting
pass in gcse.c. This pass is only enabled
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||dgregor at gcc dot gnu dot
--- Comment #3 from steven at gcc dot gnu dot org 2007-08-24 06:36 ---
It's not even supposed to pass on i686:
/* { dg-options "-O2 -march=k8" } */
(see
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.target/i386/cmov4.c?revision=127731&view=markup)
Note I'
--- Comment #6 from steven at gcc dot gnu dot org 2007-08-24 07:10 ---
Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on
gcc-patches and in this PR when I've made it pretty damn clear that I don't
want to work on gcc anymore...
--
http://gcc.gnu.or
--- Comment #2 from steven at gcc dot gnu dot org 2007-08-30 08:07 ---
Having this case vectorized might help us look better compared to other
compilers. gfortran produces a 65% slower "fatigue" binary than the faster
compiler (Sun f95, see http://www.eleves.ens.fr/ho
--- Comment #3 from steven at gcc dot gnu dot org 2007-09-05 12:35 ---
You can connect the exits by inserting fake edges. See
add_noreturn_fake_exit_edges and connect_infinite_loops_to_exit. Not sure which
one you would need in this case. Just be sure to call it before computing
(post
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
BugsThisDependsOn: 33029
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33356
--- Comment #23 from steven at gcc dot gnu dot org 2007-09-08 19:37 ---
Load PRE does still not optimize the test cases of comment #0 and comment #2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2007-09-16 21:22 ---
Won't fix for GCC 4.1.
Fixed since GCC 4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2007-10-06 12:36 ---
10 to 1 this is a problem with coming out of cfglayout mode somewhere.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from steven at gcc dot gnu dot org 2007-10-10 09:06 ---
Maybe regstack needs to be taught how to swap stack register loads to avoid the
fxch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902
--- Comment #33 from steven at gcc dot gnu dot org 2007-10-10 08:57 ---
What happened with the suggestion to only do this in reassoc2 (see comment
#27)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #11 from steven at gcc dot gnu dot org 2007-10-10 22:59 ---
*** Bug 32590 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-10-10 22:59 ---
*** This bug has been marked as a duplicate of 23286 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2007-10-11 18:52 ---
What do the edge flags look like after cprop changes the jump? EDGE_FALLTHRU
should be set.
Also, the unconditional JUMP_INSN should be removed. Unconditional jumps are
removed when going into cfglayout mode, and
--- Comment #6 from steven at gcc dot gnu dot org 2007-10-11 18:53 ---
The patch from comment #4 is wrong and should not be applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
--- Comment #8 from steven at gcc dot gnu dot org 2007-10-11 19:55 ---
Updating the CFG as suggested in comment #7 is the appropriate thing to do.
How about using delete_insn_and_edges() on the jump insn, and setting
EDGE_FALLTHRU on the remaining edge?
--
http://gcc.gnu.org
--- Comment #7 from steven at gcc dot gnu dot org 2007-10-16 13:32 ---
I would expect that tail merging (cross-jumping in gcc jargon) would merge the
two paths.
Better yet would be to optimize this earlier, and for that we need code
hoisting (re. comment #1, I think it is eliminated
--- Comment #12 from steven at gcc dot gnu dot org 2007-10-16 13:33 ---
Does not really "block" 24001, but the test case for that bug would be fixed if
code hoisting would be implemented properly.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #7 from steven at gcc dot gnu dot org 2007-10-16 13:34 ---
Does not really "block" 24001, but the test case for that bug would be fixed if
code hoisting would be implemented properly.
--
steven at gcc dot gnu dot org changed:
What
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
OtherBugsDependingO 16996
nThis
--- Comment #1 from steven at gcc dot gnu dot org 2007-10-20 10:37 ---
The first issue with code hoisting is that it can only hoist lexically
equivalent expressions. This means that dependent expressions that compute the
same value can unfortunately not be hoisted in one pass. Example
--- Comment #2 from steven at gcc dot gnu dot org 2007-10-20 10:48 ---
A second issue with code hoisting in gcse.c is that it only looks at basic
blocks immediately dominated by the branch point to hoist to. Quoting
gcse.c:hoist_code():
/* Walk over each basic block looking for
--- Comment #3 from steven at gcc dot gnu dot org 2007-10-20 10:54 ---
There is a discrepancy between the code in gcse.c:hoist_expr_reaches_here_p()
and the comment before it. Quoting:
/* Determine if the expression identified by EXPR_INDEX would
reach BB unimpared if it was placed
--- Comment #4 from steven at gcc dot gnu dot org 2007-10-20 11:08 ---
In gcse.c:compute_code_hoist_vbeinout(), the backward dataflow analysis problem
is solved using FOR_EACH_BB_REVERSE. which traverses all basic blocks through
the bb->prev_bb chain. Because the passes in gcse.c
--- Comment #5 from steven at gcc dot gnu dot org 2007-10-20 11:10 ---
>From gcse.c:compute_transpout()
/* Note that flow inserted a nop a the end of basic blocks that
end in call instructions for reasons other than abnormal
control flow. */
if (! CAL
--- Comment #6 from steven at gcc dot gnu dot org 2007-10-20 11:13 ---
Again from gcse.c:compute_transpout():
static void
compute_transpout (void)
{
basic_block bb;
unsigned int i;
struct expr *expr;
sbitmap_vector_ones (transpout, last_basic_block);
FOR_EACH_BB (bb
--- Comment #3 from steven at gcc dot gnu dot org 2007-10-21 10:00 ---
The way for you to narrow down the bug is this:
1. Compile with -daAP
2. Look in the .s file which instruction references the missing label. There
should be a LABEL_REF with a number.
3. Grep for "code_label.
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-20
11:11 ---
Should be fixed now...
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC target triplet|ia64-suse-linux |ia64
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-23
09:25 ---
Is this patch still 4.0 material? No reviewers have looked at it yet :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17790
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-23
11:19 ---
Four weeks without feedback (see #6 and #7) and works for me.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-23
11:22 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01387.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-23
11:23 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01387.html
--
What|Removed |Added
--
Bug 20100 depends on bug 20115, which changed state.
Bug 20115 Summary: [4.0 Regression] Pure functions are mishandled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20115
What|Old Value |New Value
---
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-24
15:46 ---
Can't you work around this by disabling dwarf2 support?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
801 - 900 of 3051 matches
Mail list logo
