[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-01 12:24 ---
After fixing the issue mentioned in comment#2 and comment #8, gcse.c hoisting
hoists things too far up, e.g.:
{ pred ENTRY }
BB1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
{ succ BB4 }
{ pred BB2 }
BB3
...
goto BB4
{ succ BB4 }
{ pred BB2, BB3 }
BB4
if (...) goto BB5 else goto BB6
{ succ BB5, BB6 }
{ pred BB4 }
BB5
r1 - exp1
goto BB7
{ succ BB7 }
{ pred BB4 }
BB6
r2 - exp1
goto BB7
{ succ BB7 }
{ pred BB5, BB6 }
BB7
...
{ succ EXIT }
is transformed to:
{ pred ENTRY }
BB1
r3 - exp1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
{ succ BB4 }
{ pred BB2 }
BB3
...
goto BB4
{ succ BB4 }
{ pred BB2, BB3 }
BB4
if (...) goto BB5 else goto BB6
{ succ BB5, BB6 }
{ pred BB4 }
BB5
r1 - r3
goto BB7
{ succ BB7 }
{ pred BB4 }
BB6
r2 - r3
goto BB7
{ succ BB7 }
{ pred BB5, BB6 }
BB7
...
{ succ EXIT }
when it would be better to hoist up only to BB4:
{ pred ENTRY }
BB1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
{ succ BB4 }
{ pred BB2 }
BB3
...
goto BB4
{ succ BB4 }
{ pred BB2, BB3 }
BB4
r3 - exp1
if (...) goto BB5 else goto BB6
{ succ BB5, BB6 }
{ pred BB4 }
BB5
r1 - r3
goto BB7
{ succ BB7 }
{ pred BB4 }
BB6
r2 - r3
goto BB7
{ succ BB7 }
{ pred BB5, BB6 }
BB7
...
{ succ EXIT }
GCC should not hoist up further than up to the first common dominator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #24 from steven at gcc dot gnu dot org 2008-12-01 22:00 --- Created an attachment (id=16803) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16803action=view) patch to implement code hoisting in tree-ssa-pre.c This passes bootstrap+testing on ia64-linux and amd64-linux. It causes a few vectorizer failures (4 on ia64) that I have not analyzed yet. -- steven at gcc dot gnu dot org changed: What|Removed |Added Attachment #16784|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug middle-end/38204] PRE for post dominating expressions
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-01 22:12 --- davidxl, my latest patch to bug 23286 (tree-hoist_v3.diff) makes PRE in tree-ssa-pre.c code-size aware. I have tested this with CSiBE on mips-unknown-elf. Without the patch, code size at -Os with PRE enabled is ~17% larger than -Os without PRE. With the patch, the code size increase with -Os and PRE enabled is 0.2%. With the patch and with tree hoisting enabled at -Os, code size is reduced by just a little less than 1%. With the patch and with tree hoisting enabled at -Os but RTL code hoisting disabled (i.e. the pass in gcse.c), code size is reduced by just a little less than 0.6%. (The RTL pass will be necessary mostly to hoist copies from out-of-ssa, and frame/stack pointer adjustments.) davidxl, if you have some time or someone else with time to play with this further, that'd be much appreciated. I've done my part, but having done the trick, the fun is gone and I have no intention to persue code-size aware PRE further ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38204
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-01 23:04 --- With so many dups, IMHO this ought to be fixed for the releases... -- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 15:08:11 |2008-12-01 23:04:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #26 from steven at gcc dot gnu dot org 2008-11-30 20:45 --- Resurrecting regmove is not an option. Time is better spent on figuring out what regmove does, that makes a difference, and see if IRA can be taught to do the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #28 from steven at gcc dot gnu dot org 2008-11-30 21:18 --- You're not explaining what regmove does. What transformation do these alternatives with * enable regmove to do? I'm not saying that a separate pass is not an option. Perhaps a regmove-like pass is necessary. In fact it probably is, I think even Vlad already acknowledged so. But not regmove as-we-know-it, which is a friggin' mess that ought to go away. What we should figure out IMHO, is which transformation(s) it is (are) that regmove does, which are helpful here. Maybe we can add a simple pre-regalloc pass that does these transformations, or make it part of an existing pass, using clean infrastructure (cfg, df) instead of the ad-hoc mess of regmove. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #29 from steven at gcc dot gnu dot org 2008-11-30 21:32 ---
The insns 8 in comment #0 show the regmove transformation that matters here:
With regmove disabled::
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 61)
(plus:V2SI (reg:V2SI 63 [ x ])
(mem/c/i:V2SI (symbol_ref:DI (y) var_decl 0x7f66abfb5c80 y) [2
y
+0 S8 A64]))) 992 {*mmx_addv2si3} (expr_list:REG_DEAD (reg:V2SI 63 [ x ])
(nil)))
vs. with regmove enabled:
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 63 [ x ])
(plus:V2SI (reg:V2SI 63 [ x ])
(mem/c/i:V2SI (symbol_ref:DI (y) var_decl 0x7fd36e03cc80 y) [2
y+0 S8 A64]))) 992 {*mmx_addv2si3} (nil))
This is a textbook example of a regmove transformation (where the use of the
word textbook is an insult to all textbooks ever written, since nothing in
regmove is textbook, but oh well...). It's turned a 3-address instruction
into a 2-address instruction, and this is precisely the transformation that
regmove was originally written for.
In IRA, I would've expected reg 61 and reg 63 to be coalesced to give the same
result.
Vlad already commented on this in comment #6. It's clear from his description
why IRA did not coalesce reg 61 and reg 63.
Other compilers do this kind of transformation via reverse copy propagation.
GCC could perhaps add something like that too, when it transforms a 3-address
insn to a 2-address insn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug fortran/38303] poor error message
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-29 12:22:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303
[Bug tree-optimization/26307] load PRE creates type mismatches
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-29 16:25 --- Is this still an issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26307
[Bug rtl-optimization/11826] [ARM] Minor register allocation problem before function return
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-29 19:28 --- Can an ARM maintainer please check this bug? Comment #4 suggests this bug is fixed, but it needs re-checking now that IRA has been merged. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||pbrook at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11826
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-29 22:23 --- I'm not sure if this bug is fixed, though. -ftrapv is still broken afaik. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-29 22:42 --- Looks like something alias related - so CCing Richi. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-29 22:42:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug rtl-optimization/38245] [4.4 Regression] apparent improper segfault in compiler output
--- Comment #2 from steven at gcc dot gnu dot org 2008-11-28 11:23 --- There really is obvious way to remove the argument pushes without libcall notes. There is nothing in the RTL to make clear that the pushes are dead when the call is removed, so they pushes stay. There are several ways to fix this. 1. Make the call not pure (even if the function is technically pure). IIRC the call pops the incoming arguments on return, which is clearly a non-pure side-effect. I am assuming it is acceptable that the call is not a candidate for DCE. I think this is acceptable -- it's the consequence of removing libcall notes -- but OTOH I would like to understand *why* we end up with a DCE-able pure call in the first place, why it's not optimized away in the tree optimizations. Of course, a call would only have to be non-pure if it takes arguments via the stack. For targets with proper argument passing via registers ;) the call should still be pure. 2. Make it explicit in the IL that the pushes are inputs for the call. For example, add EXPR_LISTs from the CALL_INSNs to the pushes of the outgoing args, and teach DCE to remove the insn in the EXPR_LIST when a CALL_INSN is removed. Or resurrect REG_LIBCALL_ID (renamed REG_PURECALL_ID), teach DCE to keep a list of the REG_PURECALL_IDs for removed pure calls, and do a second pass to remove all (non-CALL_INSN) insns that have the REG_PURECALL_ID of a removed libcall. This assumes that we can always remove the outgoing argument pushes if a pure call is removed. I'm not sure if this is true (is it conceivable that we CSE things in such a way that other insns would depend on the argument pushes?). Personally, I'm strongly in favor of option 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #23 from steven at gcc dot gnu dot org 2008-11-27 15:26 --- Created an attachment (id=16784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16784action=view) less unpolished version of tree code hoisting This fixes some bugs in the proof-of-concept patch: 1. Don't hoist things out of loops. We have to look at ANTIC_IN of the block we hoist into, not the union of ANTIC_IN of all its successors. 2. Add a constraint that the hoisted expression must be computed in one of the successors of the block we're hoisting too. Also added comment so that the uninitiated don't have their eye balls dropping out in confusion ;-) I might actually post this for GCC 4.5 if it subsumes the RTL code hoisting pass. -- steven at gcc dot gnu dot org changed: What|Removed |Added Attachment #16751|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug fortran/38282] Add the remaining HPF bit intrinsics
-- 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 |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-27 07:13:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-23 13:07 --- Created an attachment (id=16751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16751action=view) Proof-of-concept patch It is not terribly complicated to add hoisting to tree-ssa-pre.c. I have attached the result of roughly half a day of hacking. It is a proof-of-concept patch that demonstrates how hoisting could be added. It's not finished, tested, or even correct ;-) but it shows the general idea. For a production-quality version, one would have to make sure not to hoist expressions up too far (e.g. not further up than above the first block that generates the expression). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #17 from steven at gcc dot gnu dot org 2008-11-23 13:11 ---
For the test case of comment #0, the proof-of-concept patch does the following
in the .084t.pre dump (relevant excerpts only):
VBEOUT[2] := { {lshift_expr,a_2(D),1} (0004) }
Inserting expression 5 into AVAIL_OUT[2]
Inserted pretmp.12_8 = a_2(D) 1;
in predecessor 2
AVAIL_OUT[2] := { a_2(D) (0002), a.0_3 (0003), pretmp.12_8 (0004) }
Successor 1 not dominated by 5 - empty set
VBEOUT[5] := { }
AVAIL_OUT[5] := { a_2(D) (0002), a.0_3 (0003), a_1 (0001), pretmp.12_8 (0004) }
Successor 5 not dominated by 4 - empty set
VBEOUT[4] := { }
AVAIL_OUT[4] := { a_2(D) (0002), a.0_3 (0003), pretmp.12_8 (0004) }
Successor 5 not dominated by 3 - empty set
VBEOUT[3] := { }
AVAIL_OUT[3] := { a_2(D) (0002), a.0_3 (0003), a_5 (0005), pretmp.12_8 (0004) }
Replaced a_2(D) 1 with pretmp.12_8 in a_4 = a_2(D) 1;
Replaced a_2(D) 1 with pretmp.12_8 in a_6 = a_2(D) 1;
...
f (short unsigned int a)
{
short unsigned int pretmp.12;
short int a.0;
bb 2:
a.0_3 = (short int) a_2(D);
pretmp.12_8 = a_2(D) 1;
if (a.0_3 0)
goto bb 3;
else
goto bb 4;
bb 3:
a_4 = pretmp.12_8;
a_5 = a_4 ^ 4129;
goto bb 5;
bb 4:
a_6 = pretmp.12_8;
bb 5:
# a_1 = PHI a_5(3), a_6(4)
return a_1;
}
which eventually leads to the following in the .126t.final_cleanup dump:
;; Function f (f)
f (short unsigned int a)
{
short unsigned int a.22;
bb 2:
a.22 = a 1;
if ((short int) a 0)
goto bb 3;
else
goto bb 4;
bb 3:
a.22 = a.22 ^ 4129;
bb 4:
return a.22;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #18 from steven at gcc dot gnu dot org 2008-11-23 13:22 ---
The test case of PR38204 shows one of the problems with proof-of-concept patch,
namely the don't move up too much problem. The .pre dump looks like this:
test (int a, int b, int c, int g)
{
int pretmp.11;
int e;
int d;
int D.1257;
int D.1256;
bb 2:
pretmp.11_11 = b_3(D) * c_4(D);
pretmp.11_12 = g_8(D) + pretmp.11_11; // No need to move this up to here.
if (a_2(D) != 0)
goto bb 3;
else
goto bb 4;
bb 3:
d_5 = pretmp.11_11;
goto bb 5;
bb 4:
d_6 = b_3(D) - c_4(D);
bb 5:
# d_1 = PHI d_5(3), d_6(4)
D.1256_7 = pretmp.11_11;
e_9 = pretmp.11_12;
D.1257_10 = e_9 + d_1;
return D.1257_10;
}
Eventually this gives (in the .final_cleanup dump):
;; Function test (test)
test (int a, int b, int c, int g)
{
int d.21;
int d;
bb 2:
d.21 = c * b;
if (a != 0)
goto bb 3;
else
goto bb 4;
bb 3:
d = d.21;
goto bb 5;
bb 4:
d = b - c;
bb 5:
return (d.21 + g) + d;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #21 from steven at gcc dot gnu dot org 2008-11-23 14:20 --- I'll work on something that bootstraps and passes testing. But cost-related decisions (like the one from comment #20) are not on my TODO list right now. The pass that should do this is called sched1 ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #37 from steven at gcc dot gnu dot org 2008-11-22 09:13 --- Re: comment #35 and comment #36 That is code hoisting, again. See Bug 23286 and some the bugs closed as a duplicate of Bug 23286. Looks like it's time to implement tree-level hoisting :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23286 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug middle-end/30521] if (i == n) ++i; or i += i == n;?
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 09:51 ---
I created a t.c with both functions in it:
unsigned int f1(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return
i;}
unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
With today's trunk on x86_64, I get:
.file t.c
.text
.align 16
.globl f1
.type f1, @function
f1:
.LFB0:
leal1(%rdi), %eax
addl$2, %edi
cmpl%esi, %eax
cmove %edi, %eax
ret
.LFE0:
.size f1, .-f1
.align 16
.globl f2
.type f2, @function
f2:
.LFB1:
addl$1, %edi
xorl%eax, %eax
cmpl%esi, %edi
sete%al
addl%edi, %eax
ret
.LFE1:
.size f2, .-f2
.section.eh_frame,aw,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string zR
.byte 0x1
.byte 0x78
.byte 0x10
.byte 0x1
.byte 0x3
.byte 0xc
.byte 0x7
.byte 0x8
.byte 0x11
.byte 0x10
.byte 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB0
.long .LFE0-.LFB0
.byte 0x0
.align 8
.LEFDE1:
.LSFDE3:
.long .LEFDE3-.LASFDE3
.LASFDE3:
.long .LASFDE3-.Lframe1
.long .LFB1
.long .LFE1-.LFB1
.byte 0x0
.align 8
.LEFDE3:
.ident GCC: (GNU) 4.4.0 20081122 (experimental) [trunk revision
142117]
.section.note.GNU-stack,,@progbits
So still not the same functions.
For x86 (32bit) with -march=core2, I get similar code (f1 with a cmove).
Without a -march option, I get code with a jump.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-01-22 00:29:40 |2008-11-22 09:51:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug middle-end/30521] if (i == n) ++i; or i += i == n;?
--- Comment #6 from steven at gcc dot gnu dot org 2008-11-22 10:04 ---
Ah, now I see what Pinski meant at comment #2.
Before CSE, we still have the original code for f1:
unsigned int f(unsigned int i, unsigned int n)
{
i.20 = i + 1;
if (i.20 == n) i.20 = i.20 + 1;
return i.20;
}
After CSE (but before the first if-conversion pass) it's been transformed to:
unsigned int f(unsigned int i, unsigned int n)
{
i.20 = i + 1;
if (i.20 == n) i.20 = i + 2;
return i.20;
}
The form of the code before CSE is caught in noce_try_addcc. The second form
obviously not (because we don't know that the value of i.20 is i + 1).
So this comes down to a pass ordering problem. Or, one could argue that CSE
should not perform this transformation if (say) i.20 = i + 1 is not made dead
code by the transformation to i.20 = i + 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-22 10:53 --- The last time this bug was reconfirmed, was in March 2008. PRE has been completely rewritten since then. With today's trunk, I still see PRE take most of the compile time, but it's only 20% (on x86 and on x86_64 with Richi's testcase from t3.c.gz). Paolo, do you still see this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug rtl-optimization/21676] [4.2/4.3/4.4 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-22 10:31 --- See comment #7 and comment #13. -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23286 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #14 from steven at gcc dot gnu dot org 2008-11-22 11:17 --- Ping? Patch exists, tested and all, and just needs a re-test and then submit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug tree-optimization/26243] [4.2/4.3/4.4 Regression] reassoc is not documented in passes.texi
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 11:23 --- passes.texi *does* have documentation for the reassoc pass. Fixed by dnovillo in r114200: PR 26242 * doc/passes.texi: Add documentation for pass_vrp, pass_ipa_pta, pass_fre, pass_store_ccp, pass_copy_prop, pass_store_copy_prop, pass_merge_phi, pass_nrv, pass_return_slot, pass_object_size, pass_lim, pass_linear_transform, pass_empty_loop, pass_complete_unroll, pass_loop_prefetch and pass_stdarg. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26243
[Bug tree-optimization/21559] [4.2/4.3/4.4 Regression] missed jump threading
--- Comment #10 from steven at gcc dot gnu dot org 2008-11-22 11:36 ---
Trunk today generates the following code (this is the final_cleanup dump):
;; Function foo (foo)
foo ()
{
static char eof_reached = 0;
int bytes;
int toread;
bb 2:
toread = 4096;
bb 3:
bytes = bar (toread);
if (bytes = 0)
goto bb 4;
else
goto bb 5;
bb 4:
if (bytes != 0)
goto bb 6;
else
goto bb 7;
bb 5:
toread = toread - bytes;
bb 6:
if (toread != 0)
goto bb 3;
else
goto bb 8;
bb 7:
eof_reached = 1;
bb 8:
return;
}
Looks like we can't do any better than that -- can we??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug tree-optimization/17116] Missed jump threading/bypassing optimization with loop and % (or ands)
--- Comment #8 from steven at gcc dot gnu dot org 2008-11-22 11:45 --- I don't think anyone is interested in fixing this - WONTFIX. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17116
[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 17:34:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 17:44 --- Is there a mangling convention now for fixed-point types, or not? If not, we should make this a sorry() and resolve this bug as SUSPENDED for now. If there is, well, you know, we should add it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug c++/35335] [4.2/4.3/4.4 regression] Broken diagnostic: 'expr_stmt' not supported by dump_expr
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-22 18:20 ---
With a trivial one-liner patch this could look a lot better:
$ ./cc1plus t.C
void foo()
t.C:6: error: no match for 'operator=' in 'a = ({...})'
t.C:1: note: candidates are: A A::operator=(const A)
Execution times (seconds)
name lookup : 0.01 (25%) usr 0.00 ( 0%) sys 0.01 (25%) wall
82 kB ( 5%) ggc
TOTAL : 0.03 0.00 0.03
1508 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
$
Of course, a message reproducing the source line with a carret and all that
would be even better -- hi Aldy! -- but for now this is probably the best we
can do.
Untested, I have no commitment to this patch ;-)
Index: ../../trunk/gcc/cp/error.c
===
--- ../../trunk/gcc/cp/error.c (revision 142123)
+++ ../../trunk/gcc/cp/error.c (working copy)
@@ -1976,6 +1976,7 @@
break;
case BIND_EXPR:
+case EXPR_STMT:
case STMT_EXPR:
case STATEMENT_LIST:
/* We don't yet have a way of dumping statements in a
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35335
[Bug tree-optimization/37416] [4.4 Regression] Failure to return number of loop iterations
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-21 20:57 --- This bug is shamefully incomplete. There is no way anyone willing to give this a look can know what to look for. For example, a few things one would have to know before he/she can even begin to consider whether/how to analyze the problem: 1. What is the target where you see this? 2. What compiler flags are you using? 3. Where do you look for the number of iterations (which dump)? 4. What missed-optimization does this cause (something not vectorized)? Please read http://gcc.gnu.org/bugs.html#report before filing more bugs. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37416
[Bug target/37437] [4.4 regression] speed regression
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-21 21:13 --- What does regmove change, i.e. which of the many things that regmove does, is helpful for the test case for this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #35 from steven at gcc dot gnu dot org 2008-11-21 21:29 --- So is there a test case with current top-of-trunk that fails? This is marked as a P1 regression, but IIUC we don't even have a test case, after Jakub's fix for PR37316 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug tree-optimization/37716] [4.4 Regression] ice for legal C++ code with -O2 on 20080926
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-21 21:54 --- The reduced test case of comment #3 does not ICE on ia64 for gcc 4.4.0 20081121 (revision 142902). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
[Bug middle-end/38204] PRE for post dominating expressions
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-21 06:41 --- *** This bug has been marked as a duplicate of 23286 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38204
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-21 06:41 --- *** Bug 38204 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dann at godzilla dot ics dot ||uci dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #13 from steven at gcc dot gnu dot org 2008-11-18 21:31 --- Are things moving forward on the fwprop issue? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 21:31:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-18 21:34 --- P1 bug with a pending patch... maybe a reviewer could take a look at this (seemingly trivial) patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #9 from steven at gcc dot gnu dot org 2008-11-16 12:17 --- Advice to folks caring about compiler stability instead of supposedly faster: Always use double-queue instead of overeager. The overeager solver is just not reliable enough, and I have never found any proof for the speed benefit that Seongbae claimed it has. The theoretical worst-case time for the overeager algorithm is exponential in the number of basic blocks, for densely connected CFGs. I have argued before that such an algorithm should *never* have been selected as the default for GCC, even if it is, say, 0.5% faster for a GCC bootstrap (but I did the comparison last year and I have never actually measured any benefits of overeager over double queue). For the double queue, and also for the hybrid search, the number of passes has a reasonable proven upper bound for any CFG, so these algorithms are much more reliable. See also the discussion in PR34400, esp. comments 25-28: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400#c25 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400#c28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #5 from steven at gcc dot gnu dot org 2008-10-02 18:52 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #6 from steven at gcc dot gnu dot org 2008-10-02 18:52 --- Subject: Bug 37635 Author: steven Date: Thu Oct 2 18:51:12 2008 New Revision: 140837 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140837 Log: testsuite * gfortran.fortran-torture/execute/intrinsic_leadz.f90: New test. * gfortran.fortran-torture/execute/intrinsic_trailz.f90: New test. fortran/ PR fortran/37635 * intrinsic.c (add_functions): Add LEADZ and TRAILZ as generics. * intrinsic.h (gfc_simplify_leadz, gfc_simplify_trailz): New protos. * gfortran.h enum gfc_isym_id: (GFC_ISYM_LEADZ, GFC_ISYM_TRAILZ): New. * f95-lang (gfc_init_builtin_functions): Add BUILT_IN_CLZ, BUILT_IN_CLZL, BUILT_IN_CLZLL, BUILT_IN_CTZ, BUILT_IN_CTZL, and BUILT_IN_CTZLL. * trans-intrinsic.c (gfc_conv_intrinsic_leadz, gfc_conv_intrinsic_trails): New code-generation functions for LEADZ and TRAILZ intrinsics. (gfc_conv_intrinsic_function): Use them * intrinsic.texi: Add documentation for LEADZ and TRAILZ. * simplify.c (gfc_simplify_leadz, gfc_simplify_trailz): New functions. Added: trunk/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_leadz.f90 trunk/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_trailz.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug target/37668] Obvious bug in arm.c: arm_size_rtx_costs() case NEG:
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-28 11:57 --- Don't know if the patch is OK, but the code is obviously doing something silly. CC-ing ARM maintainer. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||pbrook at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-28 11:57:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37668
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #3 from steven at gcc dot gnu dot org 2008-09-27 14:09 --- Created an attachment (id=16414) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16414action=view) draft patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-28 00:02:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 --- I'll see this weekend if I can take care of this. -- 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 |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 22:28:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline
--- Comment #38 from steven at gcc dot gnu dot org 2008-09-21 13:07 --- Fixed by Honza's patch. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:13 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828
[Bug rtl-optimization/33356] Incomplete documentation of REG_RETVAL and REG_LIBCALL notes
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:13 --- libcall notes are no more... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33356
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:14 --- I can reproduce this on-and-off, but never with a reasonable test case. It's unlikely that anyone is interested in fixing this, esp. given that RTL PRE/CPROP are doing less and less these days as the tree optimizers improve. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug middle-end/35413] [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:19 --- Libcall blocks are no more. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35413
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #9 from steven at gcc dot gnu dot org 2008-09-21 13:21 --- Andreas, could you adopt the patch of comment #4 and see if it still fixes this bug? -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug fortran/23169] INTENT information not used in the middle-end for optimizations
--- Comment #5 from steven at gcc dot gnu dot org 2008-09-21 13:36 --- A C equivalent test case works. Once the infamous multiple-decls-per-function issue in gfortran is fixed, this bug probably will disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
[Bug target/12395] Suboptimal code with global variables
--- Comment #13 from steven at gcc dot gnu dot org 2008-09-21 13:49 --- Re. comment #12 I don't see how PRE for globals would make a difference here. In any case, AFAIU tree PRE for globals should now work, and we still don't produce any better code. The output of today (4.4.0 20080921) is still the same as that of comment #0. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-11 00:52:36 |2008-09-21 13:49:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug target/12395] Suboptimal code with global variables
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:52 ---
Here is the .final_cleanup dump, fwiw:
;; Function foo (foo)
foo ()
{
int a.1;
bb 2:
a.1 = a + 1;
a = a.1;
if (a.1 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
a = [plus_expr] a.1 + 1;
bb 4:
return;
}
which translates (on Cygwin) to:
.file t.c
.text
.p2align 4,,15
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
movl_a, %edx
leal1(%edx), %eax
movl%eax, _a
testl %eax, %eax
je L3
addl$2, %edx
movl%edx, _a
L3:
rep
ret
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-09-21 13:49:47 |2008-09-21 13:52:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:58 ---
tree PRE now *does* handle the partially redundant global variable load. This
is the .final_cleanup dump:
;; Function bar (bar)
bar ()
{
int prephitmp.13;
bb 2:
prephitmp.13 = i;
switch (prephitmp.13) default: L1, case 0: L0
L0:
foo ();
prephitmp.13 = i;
L1:
switch (prephitmp.13) default: L5, case 0: L4
L4:
foo (); [tail call]
L5:
return;
}
But we still miss the jump threading opportunity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #2 from steven at gcc dot gnu dot org 2008-07-28 20:41 --- Like Pinski said: the code before and after the patch should be identical w.r.t. TLS addresses. Without a more specific test case I'm not even going to look at this. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC|stevenb dot gcc at gmail dot| |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug tree-optimization/19790] equality not noticed when signedness differs.
--- Comment #4 from steven at gcc dot gnu dot org 2008-07-06 09:37 --- Still doesn't work. You need to replace one line for the test case of comment #0 though, because the tree optimizers are now smart enough to see that (i/32) is always 0. So replace for (i = 0; i = 10; i++) with for (i = 0; i = 320; i++) and you still get the missed optimization. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-05-05 08:36:26 |2008-07-06 09:37:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19790
[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions
--- Comment #11 from steven at gcc dot gnu dot org 2008-07-06 09:59 --- It looks like we don't use a known number of loop iterations at all anymore after this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug tree-optimization/23455] tree load PRE is not working for global variables
--- Comment #15 from steven at gcc dot gnu dot org 2008-07-06 08:53 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00430.html We should re-evaluate the need for gcse.c load-PRE after Daniel's patch goes in. The last time I looked at what loads gcse.c load-PRE would move, it only touched loads from globals, so it may be a redundant pass when tree-ssa-pre moves them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
[Bug c++/36242] OpenMP multi-threading crashes
--- Comment #3 from steven at gcc dot gnu dot org 2008-06-11 20:19 --- Jakub is the OpenMP guru. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242
[Bug tree-optimization/24028] CCP is broken
--- Comment #8 from steven at gcc dot gnu dot org 2008-06-01 09:41 --- This is now optimized by VRP, CCP, store-CCP, DOM, PRE, and TER. It's hard to break that test case! -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24028
[Bug middle-end/30789] complex folding inexact
-- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27676 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-01 21:55:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug middle-end/36414] g++ causes segmentation violation on template test program
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36414
[Bug rtl-optimization/34503] Issues with constant/copy propagation implementation in gcse.c
--- Comment #7 from steven at gcc dot gnu dot org 2008-05-24 14:31 ---
I have found a test case for the issue mentioned in comment #4. And it comes
from gcc itself:
static int *free_phinodes[10 - 2]; /* was 'tree' */
static unsigned long free_phinode_count;
void
init_phinodes (void)
{
int i;
for (i = 0; i 10 - 2; i++)
free_phinodes[i] = ((void *)0);
free_phinode_count = 0
}
When compiling this on powerpc-unknown-elf with r135815 and with the options
-O2 -fdump-rtl-gcse1-slim, I get the following RTL at the end of the GCSE
pass:
37 NOTE_INSN_BASIC_BLOCK
36 NOTE_INSN_FUNCTION_BEG
39 r164:SI=high(`*.LANCHOR0')
40 r166:SI=r164:SI+low(`*.LANCHOR0')
REG_DEAD: r164:SI
REG_EQUAL: `*.LANCHOR0'
75 r153:SI=r166:SI
REG_EQUAL: `*.LANCHOR0'
73 r165:SI=r166:SI+0x20
REG_DEAD: r167:SI
REG_EQUAL: const(`*.LANCHOR0'+0x20)
L46:
42 NOTE_INSN_BASIC_BLOCK
43 r156:SI=0x0
44 [r153:SI]=r156:SI
REG_EQUAL: 0x0
45 r153:SI=r153:SI+0x4
71 r157:SI=r166:SI
REG_EQUAL: `*.LANCHOR0'
50 r160:CC=cmp(r153:SI,r165:SI)
REG_EQUAL: cmp(r153:SI,const(`*.LANCHOR0'+0x20))
51 pc={(r160:CC!=0x0)?L46:pc}
REG_DEAD: r160:CC
REG_BR_PROB: 0x222e
52 NOTE_INSN_BASIC_BLOCK
56 [r157:SI+0x20]=r156:SI
REG_DEAD: r157:SI
REG_DEAD: r156:SI
REG_EQUAL: 0x0
This is the dump *after* CPROP2, so the post-PRE-GCSE const/copy pass has run.
Note the REG_EQUAL note on insn 71: r157:SI=r166:SI {REG_EQUAL:
`*.LANCHOR0'}. This is a reg-reg copy insn, but CPROP2 does not record the
copy. Instead it records that r157 is equal to the REG_EQUAL note value. The
result is that CPROP2 fails to copy propagate r166 into insn 56 (where r157
reaches and dies, so the copy propagation would eliminate r157).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #13 from steven at gcc dot gnu dot org 2008-05-24 15:37 --- This happens again on PPC. No test case yet. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #65 from steven at gcc dot gnu dot org 2008-05-15 05:59 --- integrated RA : 373.36 (66%) usr 0.33 ( 2%) sys 375.87 (64%) wall 12064 kB ( 2%) ggc 'nuff said. Oh, not entirely yet: IRA should have more than one timevar. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #3 from steven at gcc dot gnu dot org 2008-05-08 22:16 --- I would have thought that since this can generate an exception and it is a call insn that it would have been declared as a non deleteable insn by dce.c:deleteable_insn_p. deletable_insn_p() *will* declare this insn as non-deletable. The insn is not a NONJUMP_INSN_P so the very first check in deletable_insn_p() will already make it return false. So the problem is somewhere else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #4 from steven at gcc dot gnu dot org 2008-05-08 22:27 --- So I was looking at an older revision of dce.c. There is this new check before the !NONJUMP_INSN_P check now: /* We can delete dead const or pure calls as long as they do not infinite loop and are not sibling calls. The problem with sibling calls is that it is hard to see the result. */ if (CALL_P (insn) (!SIBLING_CALL_P (insn)) (RTL_CONST_OR_PURE_CALL_P (insn) !RTL_LOOPING_CONST_OR_PURE_CALL_P (insn))) return true; CALL_P is obviously true for this insn, and so is !SIBLING_CALL_P (there is no call_insn/j). The /u flag means that RTL_CONST_OR_PURE_CALL_P is true for the insn. The /c flag is clear, so RTL_LOOPING_CONST_OR_PURE_CALL_P is false. I don't know where RTL_CONST_OR_PURE_CALL_P is set. But that's where I would look. [ I see that RTL_LOOPING_CONST_OR_PURE_CALL_P is not documented. Kenny, can you please take care of that (and probably other necessary document updates following your patch)? ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug tree-optimization/35972] [4.4 Regression] load-PRE missed opportunities without SFTs
--- Comment #6 from steven at gcc dot gnu dot org 2008-04-19 13:09 --- Re. comment #4: If you have no idea what SCC-VN is supposed to serve, such bold statements as made in this comment are _severely_ misguided. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35972
[Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types
--- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 08:59 --- I agree with Paolo in comment #6. One purpose of the lower-subreg path was to allow backends to *not* define insns that it doesn't have. The expanders will generate inline code for such patterns at expand time, with sets to subregs. Before GCC had lower-subreg, this would lead to awful code, but now that we split the subregs out to pseudos it ought to work just fine. Sadly, even i386 still hasn't been modified to benefit from this work... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 09:07 --- Fixed, or what? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug fortran/35958] gfortran for Vista
--- Comment #1 from steven at gcc dot gnu dot org 2008-04-16 13:46 --- Looks related to http://gcc.gnu.org/ml/fortran/2008-03/msg00119.html and the thread surrounding it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #5 from steven at gcc dot gnu dot org 2008-04-16 21:02 --- This will probably only be fixed once a gfortran developer gets access to Vista... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug middle-end/35519] COMBINE repeating same matches and can SEG fault
--- 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 it?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35519
[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally
--- 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 .file t.c .text .text .p2align 4,,15 .p2align 4,,15 .globl _foo .globl _foo .def_foo; .scl2; .def_foo; .scl2; _foo: _foo: subl$12, %esp subl$12, %esp movl%ebx, 4(%esp) | movl%ebx, (%esp) movl%esi, 8(%esp) | movl%esi, 4(%esp) movl%edi, 8(%esp) call_bar movl%eax, %esi movl%edx, %edi call_barcall_bar movl%eax, %ebx movl%eax, %ebx orl %esi, %ebx movl%edx, %esi movl%edx, %esi call_bar | orl %edi, %esi orl %ebx, %eax| movl%ebx, %eax orl %esi, %edx| movl8(%esp), %edi movl4(%esp), %ebx | movl%esi, %edx movl8(%esp), %esi | movl(%esp), %ebx movl4(%esp), %esi addl$12, %esp addl$12, %esp ret ret .def_bar; .scl2; .def_bar; .scl2; -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-10 21:48:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35404
[Bug target/35466] Different assembly codes on 32bit and 64bit hosts
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-05 07:39:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35466
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- 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))
(zero_extend:DI (reg:SI 2 cx [166]
(clobber (reg:CC 17 flags))
]) 304 {*umulsidi3_insn} (expr_list:REG_DEAD (reg:SI 2 cx [166])
(expr_list:REG_DEAD (reg:SI 0 ax)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:DI (zero_extend:DI (reg:SI 0 ax))
(const_int 1000 [0x3e8]))
(nil))
The register allocator failed to make your insn satisfy its constraints.
Operand 0 is (reg:DI 4 si) but the constraint for it is =A, i.e. the ax
register.
The funny thing is that reload wants to make operand 0 be (reg:DI 0 ax), but
somehow it can't, even though (reg:SI 0 ax) dies in this insn. So apparently
the high part of (reg:DI 0 ax), i.e. (reg:SI 1 dx), lives across the insn.
This looks to me like a case of PR35404. What do you think, Ian?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet||[EMAIL PROTECTED],
||[EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- 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 pure. You must use
the result of iaddv() to avoid this:
#include limits.h
int __attribute__((noinline))
iaddv (int a, int b)
{
return a + b;
}
int main(void)
{
return iaddv (INT_MAX, 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug middle-end/35412] New: Correctness with -ftrapv depends on libcall notes
See http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01011.html ``When -ftrapv is in effect, libcalls are necessary so that the results of an operation can be propagated without making the call to the libgcc functions dead. The attached patch causes a failure in pr30286.c.'' This has to be investigated before libcall notes can be removed from the compiler. -- Summary: Correctness with -ftrapv depends on libcall notes Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement 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=35412
[Bug middle-end/35413] New: [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler
This is a placeholder bug to collect references to all issues that cause GCC to still require libcall notes. -- Summary: [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler Product: gcc Version: unknown 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
[Bug middle-end/35413] [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler
-- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||35404, 35412 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-29 23:26:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35413
[Bug middle-end/35412] Correctness with -ftrapv depends on libcall notes
--- 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
[Bug tree-optimization/35231] [4.3 Regression] VRP miscompiles libX11
--- 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
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 SCC's DFS subtree, but you won't find the comoplete SCC. I have no idea exactly what would happen, but I'm sure it would be something bad ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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's improved algorithm. Ref. 6 from that paper is also of interest. http://en.wikipedia.org/wiki/Tarjan's_strongly_connected_components_algorithm http://www.mcs.vuw.ac.nz/~djp/files/P05.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 good readon. And unless I'm mistaken, a ICE-on-valid-code bug in C or C++ is always release-blocking anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug rtl-optimization/35190] Wrong branch instruction with -freorder-blocks-and-partition on SH
--- 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
[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
--- 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
[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-14 10:13:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 algorithm, but one that still pops the SCCs in topological order. I tried once to write SCC-VN's DFS in a non-recursive way, but I never succeeded. I also tried to find a substitute for Tarjan's algorithm that possesses the properties required for SCC-VN, but also failed there. CCing Danny on this one for advice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-14 23:25:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990
--- 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: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug bootstrap/6669] Irix6.5 ada bootstrap fail in ada/targparm.adb
--- 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 |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6669
[Bug c/35163] folding comparison loses cast
--- 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||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-11 10:44:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug middle-end/34627] Incorrect branching with -Ox on hppa
--- 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
[Bug c/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- 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
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- 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
[Bug target/23322] [4.1/4.2/4.3 regression] performance regression
--- 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 we tested extensively before committing it. We have no easy way to know if any registers are carried over the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug c/35092] Global variable reference not resolved with -Os option
--- 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
