--- Comment #2 from steven at gcc dot gnu dot org 2010-02-24 09:40 ---
Missing code hoisting. Dup of another bug.
*** This bug has been marked as a duplicate of 23286 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from steven at gcc dot gnu dot org 2010-02-24 09:40 ---
*** Bug 43159 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-24 16:34 ---
Still a problem, actually worse now than before (.009t.lower dump at r156926):
;; Function foo (foo)
foo ()
{
int D.1974;
D.1974 = 1;
goto D.1975;
D.1975:
return D.1974;
}
The decomposition of return 1
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-21 14:32 ---
I have played with CSiBE with this patch:
-- 8 -
--- ../../gcc/gcc/config/arm/arm.c 2010-02-12 21:45:29.0 +0100
+++ ../../combined/gcc/config
--- Comment #13 from steven at gcc dot gnu dot org 2010-02-20 11:14 ---
We're using bugzilla to share what we find in our efforts to debug your
problem. So it is observations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-20 17:58 ---
Finally (!) posted the patch...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from steven at gcc dot gnu dot org 2010-02-18 13:53 ---
It looks like there should be a patch to dbgcnt.def.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-18 19:46 ---
Olga, is this fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-18 19:48 ---
Olga, is this fixed?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2010-02-18 23:15 ---
Richard, comment #0 has preprocessed source.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-18 23:44 ---
I can confirm the second bug, which is a checking failure in varasm.c, with GCC
4.4.2 for arm-wince-pe:
(gdb) run
Starting program: /home/stevenb/devel/build-4.4.2/gcc/cc1 -DCRASH k.c
ff_fill_linesize
Analyzing
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-18 23:58 ---
#1 0x00b4717b in assemble_variable (decl=0x77f62000, top_level=0,
at_end=1, dont_output_data=0)
at ../../gcc-4.4.2/gcc/varasm.c:2144
2144 gcc_assert (GET_CODE (XEXP (decl_rtl, 0)) == SYMBOL_REF
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-15 23:25 ---
The ipa-struct-reorg pass is broken and should be disabled for gcc 4.5 and
later, until someone gives it the TLC that it needs so badly.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-13 11:28 ---
Re. comment #8: No other compiler, I have ever seen, allows constants as PHI
args.
Single-argument PHIs should be propagated out. Do you see this in one of the
loop passes, then it's OK because they are probably
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-13 11:39 ---
In the test case of comment #2, the history of the funny PHIs is really odd. At
-O2 we end with this in the .optimized dump:
bb 3:
# i_1 = PHI 0(2)
# s_11 = PHI 0(2)
bb 4:
# i_12 = PHI i_1(3), i_7(4
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-13 12:44 ---
Re. comment #12, if you mean the extra BB3, that one is not really extra, it
comes from loop header copying, and it easy to clean up. I assume ifcvt cleans
this up?
Re. comment #12, yes that is expected, but most
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2010-02-13 23:18 ---
Breakpoint 7, rest_of_handle_sched2 () at ../../trunk/gcc/sched-rgn.c:3534
3534 ! maybe_skip_selective_scheduling ())
(gdb) p brief_dump_cfg(stderr)
Basic block 2 (reachable, rtl)
Predecessors: ENTRY
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-13 23:29 ---
This is a gem, the scheduler attempts to schedule the prefetch *after* the
return.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-14 00:07 ---
User prefetches should never be scheduled. Andreas Krebbel posted a patch
towards that (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00130.html) but he
hasn't followed up on it, so far.
Of course, in very rare
--- Comment #20 from steven at gcc dot gnu dot org 2010-02-12 20:57 ---
What is the plan for this bug, fix it for GCC 4.5.0 or for later?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
--- Comment #18 from steven at gcc dot gnu dot org 2010-02-12 21:11 ---
As far as I'm concerned, this is WONTFIX for all affected compilers.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-12 21:37 ---
I'm not working on this = unassign.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-12 21:46 ---
On x86_64 the two functions still give different code:
;; Function strength_test2 (strength_test2)
strength_test2 (int * data)
{
unsigned int ivtmp.12;
int * pretmp.9;
int * pretmp.7;
int k;
int D.2743
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 21:49 ---
Not worth pursuing, since RTL is only a tiny amount of memory these days (with
all GIMPLE function bodies and all DF info in memory also).
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from steven at gcc dot gnu dot org 2010-02-12 21:58 ---
GCC still doesn't get it right for this PR. The .139t.optimized dump for trunk
r156706:
;; Function foo (foo)
foo ()
{
int a.1;
int a.0;
bb 2:
a.0_1 = a;
a.1_2 = a.0_1 + 1;
a = a.1_2;
if (a.1_2 != 0
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-12 22:01 ---
Waiting for a m68k maintainer to do something here...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-12 22:02 ---
Waiting for a m68k maintainer to do something here...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 22:02 ---
Waiting for a m68k maintainer to do something here...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-12 22:03 ---
Waiting for a m68k maintainer to do something here...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-12 22:04 ---
No test case. No action.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-12 22:05 ---
No test case. No action.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19202
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 22:06 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 22:27 ---
Basically yet another example of why it is a REALLY BAD IDEA to use constants
as PHI arguments. If the constant from s =0 would not be propagated into the
PHI, the statement would not be dead and removed, and no new
--- Comment #20 from steven at gcc dot gnu dot org 2010-02-12 22:46 ---
Bug 27016 is another example of poor IVOPTS due to poor choices in
arm_arm_address_cost
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2010-02-12 22:52 ---
If arm_arm_address_cost is fixed to return 1 unconditionally, the expected
code of comment #5 comes out at -Os, with the bonus of one less branch:
testme:
ldr r2, .L4
ldr r1, .L4+4
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-12 23:08 ---
Can you explain how? It's not clear from the code of your comment #2 how a
simplification would cause the extra basic block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-11 20:45 ---
If you cannot reproduce this problem on a target that exist in the official
FSF GCC release, please close this PR as INVALID and contact the people you got
your compiler from (and while at it -- please ask them
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-10 09:46 ---
What is the purpose of regmove these days, anyway? Isn't it all useless code
thanks to IRA?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973
--- Comment #51 from steven at gcc dot gnu dot org 2010-02-10 10:42 ---
Could the OP be so kind to see if this is still a problem? And, if this is
still a problem with an unpatched compiler: whether the problem goes away if
arm_arm_address_cost() returns 1 unconditionally (so
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-10 10:55 ---
Reconfirmed with r156595 and r156650 (with and without -fschedule-insns, and
-fsched-pressure makes no difference either).
Vlad, you added some register pressure awareness to the scheduler. Do you think
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-10 11:01 ---
This is a regression, so let's mark it as such.
Shin-wei, is it possible for you check what GCC 4.3 does. Bonus if you can
check a 4.4 snapshot from just before and just after IRA was merged.
--
steven at gcc
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-10 13:00 ---
My compiler is configured for arm-elf, I guess that's the difference...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
--- Comment #11 from steven at gcc dot gnu dot org 2010-02-10 13:04 ---
Closed for wrong ABI.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2010-02-10 16:27 ---
Trying with r156650, I get this before regalloc (in the .184r.asmcons dump):
1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
2 r135:SI=r0:SI
REG_DEAD: r0:SI
3 NOTE_INSN_FUNCTION_BEG
6 r136:SI
--- Comment #13 from steven at gcc dot gnu dot org 2010-02-10 17:23 ---
As comment #12 shows, CSE can't do much about this -- there is no common
subexpression before register allocation.
Vlad, this is another one that you probably should have a look at, please.
I will have a look
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-10 17:50 ---
Vlad, this is another one that you probably should have a look at, please.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2010-02-10 19:24 ---
The difference between r118474 (left) and r118475 just before register
allocation (in the .life2 dumps) is this:
2 NOTE_INSN_DELETED 2 NOTE_INSN_DELETED
8 NOTE_INSN_BASIC_BLOCK
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-10 22:50 ---
In fwprop.c of r118475, we get to propagate_rtx_1 (fwprop.c:334):
/* Copy propagations are always ok. Otherwise check the costs. */
if (!(REG_P (old) REG_P (new
--- Comment #19 from steven at gcc dot gnu dot org 2010-02-10 23:47 ---
In r118474, cse.c:find_best_addr makes the replacement here:
if ((addr_folded_cost addr_cost
|| (addr_folded_cost == addr_cost
/* ??? The rtx_cost comparison is left
--- Comment #20 from steven at gcc dot gnu dot org 2010-02-10 23:53 ---
I'll leave it to someone else to implement and test the details...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-08 10:47 ---
Trunk today produces this (with -dAP hacked to print slim RTL):
.file t.c
.text
.align 2
.global longfunc
.type longfunc, %function
longfunc:
@ args = 0, pretend
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-08 10:51 ---
Add an ARM guy to the CC:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-08 11:15 ---
test:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl func
add sp, sp, #12
--- Comment #6 from steven at gcc dot gnu dot org 2010-02-08 11:18 ---
Does the ARM backend already support conditional compares?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-08 11:22 ---
Patch of comment #3 from Ramana was never committed to the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-08 11:29 ---
Trunk today (r156595) produces this:
repl1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
mov r4, r0
mov r1, #0
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-08 12:14 ---
Richard, can we split thumb2_compare_scc? If so, when/how would you do this?
(I'm thinking of a post-RA splitter, but perhaps it could be done earlier.)
--
steven at gcc dot gnu dot org changed:
What
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-08 12:49 ---
The duplication of sp in r4 is tracked in a separate bug report, bug 42500.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
--- Comment #7 from steven at gcc dot gnu dot org 2010-02-08 16:11 ---
New test case is with func defined extern, as already mentioned in comment #5:
extern void func(char c, int t);
void foo(int u)
{
func ( 8, (u 24) 0xffL );
func ( 8, (u 16) 0xffL );
func ( 8, (u 8
--- Comment #6 from steven at gcc dot gnu dot org 2010-02-08 16:27 ---
Must be a regression from some version, if POINTER_PLUS_EXPR is the reason for
this extra NEG. Matz knows TER best these days, so matz - cc.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from steven at gcc dot gnu dot org 2010-02-08 16:45 ---
Trunk today (r156595) optimizes this at -O1, -Os, and -O2 in the tree
optimizers. The .fre pass removes the first func call, then .dom1 removes the
next two. The .dom2 pass removes the remaining one.
If I add
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-08 18:45 ---
FWIW, bootstrap+regtest succeeds on ia64-unknown-linux-gnu with the patch set
applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42617
Severity: normal
Priority: P3
Component: tree-optimization
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=43001
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-08 22:16 ---
Right then, sorry for the noise :-)
I hope someone will be kind enough to add those test cases to trunk, too...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
--- Comment #1 from steven at gcc dot gnu dot org 2010-02-05 10:44 ---
Be careful about naming RVCT.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
GCC target triplet: arm-elf
BugsThisDependsOn
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-05 12:07 ---
Looks fixed on ARM. Pinski, what say you on ppc?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-02-05 12:42 ---
In the .expand dump there is already something funny about the code generated
for the bit field expressions.
For example the code generated for this:
D.1966_8 = D.1965_7 1;
if (D.1966_8 != 0)
TER will perform
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-05 12:45 ---
This is both a tree-optimization and an rtl-optimization problem, so setting
component to middle-end (there is no generic optimization component
anymore).
--
steven at gcc dot gnu dot org changed
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-05 13:33 ---
I'm trying to coerce IVOPTSs into producing the following, optimal code in the
GIMPLE optimizers (without much luck, so far):
bb 2:
pretmp.11_26 = (int) s_11(D);
ivtmp.20_28 = (long unsigned int) b_inout_5(D
--- Comment #18 from steven at gcc dot gnu dot org 2010-02-05 14:02 ---
I used -O2 -std=c99 -mcpu=arm9 -funroll-loops and I manually hacked the cost
in GDB to change from:
Address costs:
index costs 6
cst + index costs 2
...to this...:
Address costs:
index costs 1
cst + index
--- Comment #19 from steven at gcc dot gnu dot org 2010-02-05 14:58 ---
Interesting: for -march=armv5te -mthumb the code after IVOPTS is the perfect
code (from e.g. comment #17). The reason is that the address cost function for
Thumb (arm_thumb_address_cost) is of course not the same
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-04 11:21 ---
I'm going to crack this bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2010-02-04 14:54 ---
With the patches from bug 42617 applied, I get the following:
.file tst.c
.text
.align 2
.global Unroll
.type Unroll, %function
Unroll:
@ args = 0, pretend = 0
--- Comment #13 from steven at gcc dot gnu dot org 2010-02-04 14:56 ---
With -fno-web, the patches from bug 42617 do not help and the output is the
same as that of comment #8 (second asm dump).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-04 15:19 ---
Part of the problem comes from the way IVOPTS optimizes the memory access:
;; Generating RTL for gimple basic block 3
;; D.1814_10 = MEM[base: D.1846_29];
(insn 52 51 0 tst.c:6 (set (reg:SI 172 [ D.1814
--- Comment #50 from steven at gcc dot gnu dot org 2010-02-04 16:04 ---
Bernd Schmidt has worked on this, see here:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01788.html
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00268.html
It is hard to tell whether this has actually addresses
--- Comment #15 from steven at gcc dot gnu dot org 2010-02-04 16:06 ---
The patches for bug 31849 have been commited, it seems, and it doesn't help for
this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-04 22:52 ---
Still not fixed. Still the major source of RTL jump threads.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
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=42963
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-03 21:49 ---
Ah, Set aside the standard. Another user who wants to make up his own
semantics for a standardized language. No, no, and damn no.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
--- Comment #26 from steven at gcc dot gnu dot org 2010-02-02 18:06 ---
Re. comment #25:
So does that mean this is not a 4.5 regression anymore? If so, please adjust
the summary also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-01 11:32 ---
On a not-completely-OT note: Can anyone explain what this WITHOUT_GPLV3 is
about? I can't find any mentioning of it on freebsd.org...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
--- Comment #24 from steven at gcc dot gnu dot org 2010-02-01 22:13 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from steven at gcc dot gnu dot org 2010-01-31 11:31 ---
GCC 4.2 is no longer maintained, and the code that ICEs had been almost
completely rewritten. Does this also fail with newer compilers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-30 15:33 ---
What is msp430-gcc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722
--- Comment #10 from steven at gcc dot gnu dot org 2010-01-30 16:14 ---
That CD-DCE stuff has by now deviated so far from the text book
implementation that I don't recognize it anymore at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-30 16:37 ---
The loop is deemed necessary because the loop block (bb 6) is control dependent
on itself (?!):
(gdb)
mark_control_dependent_edges_necessary (bb=0x77f264e0, el=0x142c5d0) at
../../trunk/gcc/tree-ssa-dce.c:388
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-30 16:42 ---
Even more fun: mark_control_dependent_edges_necessary is called on basic block
6 because a PHI argument is fed to j_1 = PHI j_5(D)(2), 0(6) i.e. a
constant coming from basic block 6:
#1 0x00a16627
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-30 16:45 ---
Hack that may be worth trying:
Index: tree-ssa-dce.c
===
--- tree-ssa-dce.c (revision 156352)
+++ tree-ssa-dce.c (working copy)
@@ -683,7
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-30 16:51 ---
Eh, ignore comment #3. My understanding of CD-DCE really *is* rusty :-).
Being more careful now: IIRC the statement j = 0 would have been control
dependent on if (b) and marking j = 0 would result in marking if (b
--- Comment #9 from steven at gcc dot gnu dot org 2010-01-30 17:30 ---
The loop is also properly eliminated if I split the (critical) edge from bb6 to
bb5 the edge that brings in the constant 0 to the j_1 = PHI j_4(D)(2),
0(6).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
--- Comment #10 from steven at gcc dot gnu dot org 2010-01-30 20:32 ---
The safe thing to do, may be to ignore self control dependence, like so:
- 8 --
Index: tree-ssa-dce.c
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-30 21:17 ---
You get what you deserve:
$ gcc-4.5.0 -S -O2 -fstrict-aliasing -Wstrict-aliasing=2 q.c
q.c: In function 'main':
q.c:15:2: warning: dereferencing type-punned pointer might break
strict-aliasing rules
301 - 400 of 3017 matches
Mail list logo
