--- Comment #5 from steven at gcc dot gnu dot org 2008-01-21 11:52 ---
I thought inlining is disabled for mismatching function prototype/definition?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-21 14:38 ---
> The similar
> condition for reaching definitions is not liveness, but absence of
> uses. To trim reaching definitions, one should really be looking at
> the last reachable use of a definition, and tri
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-21 17:10 ---
It's been half a year since anyone said anything about this bug...
Ian, pinski asked you a question. Thoughts?
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-22 06:06 ---
...and does not ICE with version...?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2008-01-22 21:01 ---
There is some discussion about this bug in the following thread on gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00326.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
--- Comment #48 from steven at gcc dot gnu dot org 2008-01-23 08:52 ---
The priority of this bug is too high. If it wasn't just for recording that
this behavior exists in VRP and CPROP, I would propose to just close this bug
as WONTFIX. The test case is just too obscure, no m
--- Comment #36 from steven at gcc dot gnu dot org 2008-01-23 08:54 ---
What is the relation between the LIM patch and the alias oracle patch that was
floated some time ago?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-23 11:27 ---
It is not always a win. A function called once on a cold path should not be
inlined for e.g. icache reasons.
For your test case however, CS1 should have been inlined.
--
steven at gcc dot gnu dot org changed
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-23 16:20 ---
CCing the canonical type expert.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-23 16:30 ---
What would be the semantics of "weak" on a template member? That is, how would
the weak reference be overridden?
What I'm looking for is an example of what GCC did with this declaration when
it was
--- Comment #4 from steven at gcc dot gnu dot org 2008-01-27 15:05 ---
Fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
--- Comment #32 from steven at gcc dot gnu dot org 2008-01-27 15:35 ---
I have re-tested Zdenek's patch on arm-unknown-elf.
128 files are smaller with the patch, and 126 files are larger. The total size
increase with the patch is 324 bytes on 3601910 bytes total size (or <0.0
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-29 07:29 ---
Zap.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from steven at gcc dot gnu dot org 2008-01-30 09:10 ---
How did you configure gcc (i.e. command line)? What is the output if you
compile with -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- Comment #14 from steven at gcc dot gnu dot org 2008-01-30 12:35 ---
Patch in comment #9 works for me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-31 14:47 ---
Eh, how is this a regression? Was struct-reorg in 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
--- Comment #9 from steven at gcc dot gnu dot org 2008-02-01 11:53 ---
Mine to investigate.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #15 from steven at gcc dot gnu dot org 2008-02-01 13:19 ---
CCing half the world is not going to help anyone.
Try adding TODO_df_finish.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-03 11:39 ---
According to comment #5, the loop2 pass creates the RTL that exposes the
problem in combine. I don't believe that this is really true. There is no
loop in the test case, so the loop2 pass should be a NOP. At
--- Comment #7 from steven at gcc dot gnu dot org 2008-02-03 12:05 ---
The trunk also inlines ret1() at -O2, and therefore does not fail.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2008-02-03 12:26 ---
We call try_combine() with the following insns:
i1:
(insn 8 7 9 2 t.c:4 (set (reg/v:SI 94 [ i ])
(reg:SI 28 %r28)) 37 {*pa.md:2542} (expr_list:REG_DEAD (reg:SI 28 %r28)
(nil)))
i2:
(insn 31 10 32 2
--- Comment #9 from steven at gcc dot gnu dot org 2008-02-03 12:54 ---
Further investigation shows that simplify_if_then_else() called from
combine.c:5211 (combine.c r131744) turns this:
(if_then_else:SI (ge (reg/v:SI 94 [ i ])
(reg:SI 98))
(neg:SI (reg/v:SI 94 [ i
--- Comment #10 from steven at gcc dot gnu dot org 2008-02-03 13:19 ---
The following code from simplify_if_then_else() triggers:
/* Look for cases where we have (abs x) or (neg (abs X)). */
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_CODE (false_rtx
--- Comment #11 from steven at gcc dot gnu dot org 2008-02-03 13:25 ---
My RTL fu is not sufficient to determine whether the following one-liner patch
is DTRT. Eric, could you have a look at this, please?
Index: combine.c
--- Comment #14 from steven at gcc dot gnu dot org 2008-02-03 14:02 ---
Instead of const0_rtx, I probably should have used CONST0_RTX(mode) ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34627
--- Comment #3 from steven at gcc dot gnu dot org 2008-02-03 14:19 ---
Might be fixed, several c++ bit field issues were recently fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2008-02-03 14:21 ---
No test case, no activity, and, really, quite old already. Please re-open if
you can still reproduce this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-03 14:25 ---
Reported fixed by the reporter. I also can't reproduce it with trunk of today.
Likely fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00558.html.
--
steven at gcc dot gnu dot org changed:
--- Comment #8 from steven at gcc dot gnu dot org 2008-02-03 14:57 ---
I don't see this FAIL in any recently reported test results (on the
gcc-testresults mainling list) for powerpc-linux or powerpc64-linux. Thus,
fixed.
--
steven at gcc dot gnu dot org changed:
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-03 14:42 ---
Is this still an issue now that GCC has emultls?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from steven at gcc dot gnu dot org 2008-02-03 14:32 ---
Honza forgot to close this, it seems.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from steven at gcc dot gnu dot org 2008-02-03 14:52 ---
This is a really old bug. What is the remaining issue that is being tracked
here? Or can this bug report be closed now?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-03 14:35 ---
Should be fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-03 14:37 ---
Test case and HOWTO reproduce would be welcome.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-03 14:39 ---
Andrew, ping about your fix?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2008-02-04 18:12 ---
oops, sorry!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-05 17:28 ---
Duplicates have always existed. E.g. -dr and -dG have been overloaded for as
long as I can remember using them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35094
--- Comment #23 from steven at gcc dot gnu dot org 2008-02-06 09:00 ---
The IS_STACK_MODE trick is mine, and if this affects SSE code generation, the
bug is that IS_STACK_MODE returns true for registers that will not go on the
stack.
I acknowledge the IS_STACK_MODE is a big hammer, but
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-06 09:05 ---
There was -Wnull-dereference once. I don't know if it still exists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35092
--- Comment #26 from steven at gcc dot gnu dot org 2008-02-06 11:43 ---
You could read up on the following mailing list threads if you want to know
where the IS_STACK_REG check comes from:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01859.html
http://gcc.gnu.org/ml/gcc-patches/2006-02
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-08 17:27 ---
See PR31360. May be fixed for GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-08 23:05 ---
Is it possible to create an equivalent C test case (e.g. from the initial
GIMPLE dumps before the ICE)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #23 from steven at gcc dot gnu dot org 2008-02-09 09:20 ---
Please fix the ChangeLog entries. You forgot the asterisk "*" before combine.c
in every commit you made.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34627
--- Comment #22 from steven at gcc dot gnu dot org 2008-02-12 07:10 ---
Zap.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-11 10:44 ---
CCing fold guru.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-13 22:04 ---
I also can't reproduce it (neither on native nor with a cross).
Any local patches? Maybe you can reduce it to a set of simpler configuration
options?
--
steven at gcc dot gnu dot org changed:
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-14 10:10 ---
At least add a comment please why REG_CROSSING would need special treatment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35190
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-14 10:12 ---
ICE on valid code should be P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-14 23:25 ---
Should be P1.
This bug is shows an intrinsic scalability problem with SCC-VN as it is
implemented right now (and presented in the literature).
The key issue is, SCC-VN should use a non-recursive SCC finding
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
--- Comment #10 from steven at gcc dot gnu dot org 2008-02-15 16:20 ---
Re. comment #7, sure this can be P1 and block the release. SCC-VN doesn't have
to be fixed for the release. This bug can be worked around.
Not making a bug P1 because you want a release out the door is not a
--- Comment #13 from steven at gcc dot gnu dot org 2008-02-16 09:33 ---
Re. comment #8
You can't terminate the DFS before a complete SCC is found, it will break the
correctness of the SCC-VN algorithm. You'd start another DFS from a
not-yet-marked SSA name that is in the
--- Comment #14 from steven at gcc dot gnu dot org 2008-02-16 09:40 ---
For those who have no idea what we're talking about, check out these links.
The first link is Tarjan's algorithm, which is what the tree-ssa-sccvn.c
SCC-finder is based on. The second link is Pearce&
--- Comment #4 from steven at gcc dot gnu dot org 2008-02-17 14:51 ---
Does this affect 4.2 too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35231
3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35413
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35404, 35412
Status|UNCONFIRMED |NEW
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-29 23:36 ---
PR19020 shows that -ftrapv vs. libcalls is broken even without Paolo's patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
--- Comment #7 from steven at gcc dot gnu dot org 2008-03-01 10:50 ---
With trunk as of today, the test case of comment #0 does trap if optimization
is disabled. At -O, the libcall is optimized away, but the call to iaddv() from
main() is also optimized away because iaddv is found to be
--- Comment #11 from steven at gcc dot gnu dot org 2008-03-03 19:35 ---
Quoting your insn once more:
(insn 58 57 59 6 gnu/java/nio/natVMSelector.cc:82 (parallel [
(set (reg:DI 4 si [165])
(mult:DI (zero_extend:DI (reg:SI 0 ax
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2008-03-10 20:04 ---
The patch makes adding log use an algorithm quadratic in the number of log
links per insn. It is probably better to:
1. build the log links.
2. filter out the duplicates as a post pass (and maybe sort them while at
--- Comment #3 from steven at gcc dot gnu dot org 2008-03-10 21:48 ---
IRA does not handle this either with -fno-split-wide-types. Left is IRA as-is
with -O2 -fomit-frame-pointer. Right is same options + -fno-split-wide-types.
.file "t.c"
--- Comment #40 from steven at gcc dot gnu dot org 2009-01-31 22:22 ---
Comparing optimized build times *is* very, very fair as we add optimization
capabilities that help nothing for 99% of the code (cselim, bswap optimization,
cestore, etc.), and with a passes pipeline that
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-05 14:23 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 11:59 ---
I am unable to reproduce this on Cygwin. Anyone got a .gcse dump for me?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-06 17:50 ---
Re. comment #2:
This looks more like normal PRE over exception edges, which AFAIK tree-ssa-pre
does not do (it keeps ANTIC_IN empty for any block that has abnormal
predecessors).
--
steven at gcc dot gnu dot org
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 20:58 ---
The "near obvious cse" cases are not obvious (requires reassociation). To make
them redundant, you need code hoisting.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-06 21:02 ---
Can't reproduce this with any compiler I've tried.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-06 21:06 ---
What happened to this one since, ehm, 2.5 years ago?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 21:06 ---
What happened to this one since, ehm, 2.5 years ago?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:10 ---
"There is no flow..."
Fixed with df merge.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-06 21:15 ---
Not reproducible, and gcc 3.4 is not supported anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-06 21:21 ---
GCC has the bt-load optimization for this. But this code is not enabled for
ia64. It could be so simple as just setting flag_branch_target_optimize{,2} to
true in the ia64 backend, but maybe more work is needed (I
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-06 21:34 ---
Confirmed with gcc 4.3. Where do we stand today?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:35 ---
GCC 3.3 is not supported anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:39 ---
Confirmed with GCC 4.3 (ubuntu).
I recently fixed one of the worst bottlenecks in the 'expand' phase, so this
may be fixed in GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 21:41 ---
We have a new candidate: bswap optimization.
Diego's idea to do "a single scan that calls back to all these transformations
on every statement" really still sounds like The Right Thing to do.
--
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:43 ---
c4x is no longer supported.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:45 ---
This would be fixed if someone would fix the Sign Extension Elimination pass
(yes, it also handles zero extensions). But that pass is probably broken
beyond repair at this point, and likely needs a rewrite instead
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:46 ---
ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33524
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:52 ---
Confirmed. Looks like something for postreload-gcse to handle. Before that,
there are no partial redundancies in the RTL (at least, not in the quick look I
gave it).
--
steven at gcc dot gnu dot org changed
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:53 ---
Could be added to PPRE.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 22:01 ---
Confirmed with r143992. The tail call is correctly identified in the
.final_cleanup dump, but not expanded to a tail call.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-06 22:16 ---
Looks like it really was a dup. Can't reproduce it anymore now, anyway.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 22:17 ---
Unable to reproduce. Seems to work, even!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-06 22:43 ---
Then they should be grouped. And kept grouped.
Here's one case where there has to be a trade-off between micro-optimizations
for specific cases, and compile time for everyone. Please, for once, let us
seri
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-08 14:13 ---
This is a really old bug. Since 2005, a lot has happened in GCC. Could
someone interested in AVR please check whether this is still an issue?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-08 14:15 ---
This is a really old bug with no changes for a long time. Could someone check
whether there still is an issue here, and if so, confirm the bug?
Uros, I added you because you seem to be interested in Alpha lately
--- Comment #16 from steven at gcc dot gnu dot org 2009-02-08 14:17 ---
No news for almost three years. Where are we with this one today?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-08 14:20 ---
No news since almost two years ago. Is this still a problem?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-12 11:26 ---
Even for code with lots of computed gotos, the CFG should not be fully
connected. We factorize computed gotos to avoid exactly that. At least we used
to. Maybe the factorizing is broken, or it is undone somewhere
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-12 12:01 ---
In the past, we did not unfactor them (see e.g. Bug 15242).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-12 12:49 ---
If there is a test case that compiles in less than 4GB, I'll take this bug (I
have no access to machines with more memory than that ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #20 from steven at gcc dot gnu dot org 2009-02-13 07:44 ---
Re: "Moving loop invariants out of this loop might help if it detected as a
loop, but I don't know how to check whether it is." (Comment #19):
It's not like there will not be any loop invaria
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-13 10:03 ---
Re. Comment #14
No, this is not crazy. It is called postreload-gcse. But it is a stupid pass
that doesn't handle all cases it ought to handle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-16 23:13 ---
Hours is excessive alright.
Unfortunately, there are a couple of things missing to reproduce your problem.
There has to be at least a test case (preprocessed source), and the output of
gcc when you compile the test
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-17 06:31 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
1001 - 1100 of 3051 matches
Mail list logo
