[Bug rtl-optimization/68173] gcc takes a long time and a lot of memory with -O0 on source file with very large expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68173 --- Comment #15 from stevenb.gcc at gmail dot com --- > I wonder if we should (finally) use a RB tree for bitmap. I even remember > some patches posted to improve this (from Steven?) this or last year? I used splay trees, they're a lot easier than balanced trees like RB or AVL. https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00170.html
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #11 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com --- --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- I have tried to compile gcc.dg/comp-goto-1.c with the patched gcc, but compilation failed with: Huh, worked for me. What revision, what compiler options did you use?
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950 --- Comment #8 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com --- --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- That still doesn't look safe -fcompare-debug wise. I mean, if BB ends in a DEBUG_INSN (or more), it could be preceeded by note, label, or some other insns. So shouldn't that be instead rtx insn2 = DEBUG_INSN_P (insn) ? prev_nondebug_insn (insn2) : insn; I suppose so, yes. (I'd hope there shouldn't be DEBUG_INSN only bb's, because then with -g0 insn ought to be NULL and NEXT_INSN (insn) should crash), and use this in the !NOTE_P and !LABEL_P tests? This block is a DEBUG_INSN-only block, but insn is never NULL: BB_END will be the basic block note.
[Bug web/55237] Linkify r123456 in comments to point to SVN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237 --- Comment #15 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com --- --- Comment #14 from Frédéric Buclin LpSolit at netscape dot net --- On the other hand, you are free to not click on a register name which is linkified. That is true, but it's a bit distracting. Let's not bike shed over this. It's nothing major, only nice-to-have :-)
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #13 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-04-21 21:36:32 UTC --- Steven, is it possible to emit NOTE_INSN_EH_REGION_END in such way that it would not split the call and its NOTE_INSN_CALL_ARG_LOCATION? This would solve the above problem in the most elegant way. The most elegant way is to not use NOTE_INSN_EH_REGION notes. I don't like the proposed fix, the notes should be created only for final.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #10 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-04-08 19:42:51 UTC --- Sure. Do you know any package that combines C++ EH with IEEE exceptions? I don't. In fact, I don't actually know of a package that wants to enable trapping fp math at all. I barely know a thing about EH, or IEEE exceptions, let alone a combination or two. I'm a doc^Wn aerospace engineer, not a computer scientist. Do you believe that you're going to be able to delete the notes entirely, and that it's only Alpha that's keeping them alive? That's certainly not true, I assure you. Removing the notes entirely is the goal eventually, but I'd settle for making them local to final.c for now. What besides alpha and final are keeping these notes alive? You've probably seen my grep results, and at least from passes.c there doesn't seem to be anything between pass_convert_to_eh_region_ranges and pass_final that would use the INSN_NOTEs: NEXT_PASS (pass_convert_to_eh_region_ranges); NEXT_PASS (pass_shorten_branches); NEXT_PASS (pass_set_nothrow_function_flags); NEXT_PASS (pass_dwarf2_frame); NEXT_PASS (pass_final); AFAIU the only code transformations done in these passes are in shorten_branches that shouldn't care whether it's dealing with the REG_EH_REGION notes or the NOTE_INSN_EH_REGION notes. But my U in AFAIU is obviously no-where near your U when it comes to EH, so if you can explain a bit, I'd really appreciate it! :-) (On the topic of notes: note to self, kill NOTE_EH_CONTEXT.)
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #18 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-03-30 12:54:12 UTC --- * It would be extremely nice to update the testsuite to check the locations are correct. This is unfortunately a lot of boring work, so if I cannot get help to do this, I hope it is not a pre-condition for approval. You mean for existing test cases? I will help with that, just say what/where/when ;-)
[Bug libgcc/56460] _Unwind_Find_FDE is O(n) in the number of frame infos, (and LLVM's JIT will generate many of them)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460 --- Comment #5 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-02-27 21:09:55 UTC --- --- Comment #4 from Chris Reed cr at progress dot com 2013-02-27 12:15:52 UTC --- Yes, I'm happy to address the copyright issue - the copyright disclaimer route seems simpler. I can take care of a patch along the lines of your idea. Working on it already. It's too late now for GCC 4.8 but I will attach the patch to this bug report when it's ready.
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #22 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-02-25 19:54:59 UTC --- Looking for targets that occur in both lists (and ignoring mips) I find only picochip. So, AFAIU, PR56242 might still trigger for picochip. No. It is impossible for a target to have SEQUENCEs and a CFG at the same time. The CFG code doesn't handle SEQUENCEs. Having SEQUENCEs for delay slots in the CFG would result in a verify_flow_info failure, because there would be non-jump insns (i.e. the SEQUENCE) at the end of basic blocks ending in a branch. Any target pretends to have a valid CFG and SEQUENCEs at the same time is broken.
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #23 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-02-25 19:59:09 UTC --- For all these targets, we recompute the CFG at the start of pass_machine_reorg: ... $ egrep '(compute|free)_bb_for_insn' gcc/config/*/* gcc/config/arm/arm.c: compute_bb_for_insn (); gcc/config/bfin/bfin.c: compute_bb_for_insn (); gcc/config/c6x/c6x.c: compute_bb_for_insn (); gcc/config/frv/frv.c: compute_bb_for_insn (); gcc/config/i386/i386.c: compute_bb_for_insn (); gcc/config/ia64/ia64.c: compute_bb_for_insn (); gcc/config/mep/mep.c: compute_bb_for_insn (); gcc/config/mips/mips.c:compute_bb_for_insn (); gcc/config/mips/mips.c: free_bb_for_insn (); gcc/config/mn10300/mn10300.c: compute_bb_for_insn (); gcc/config/picochip/picochip.c: compute_bb_for_insn (); gcc/config/spu/spu.c: compute_bb_for_insn (); gcc/config/spu/spu.c: free_bb_for_insn (); gcc/config/spu/spu.c: compute_bb_for_insn (); gcc/config/spu/spu.c: free_bb_for_insn (); gcc/config/tilegx/tilegx.c: compute_bb_for_insn (); gcc/config/tilepro/tilepro.c: compute_bb_for_insn (); For GCC 4.9 we should make freeing the CFG late the default. I have patches for that in my queue already.
[Bug debug/53948] [4.8 Regression] Assignment line missing for -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53948 --- Comment #6 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-02-07 20:24:07 UTC --- On Thu, Feb 7, 2013 at 9:04 PM, law at redhat dot com wrote: The real way to get the prior behaviour without reverting the patch is to either explicitly mark parameters so we can check for them in this one hunk of code. That is what I did in http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00847.html Or to create a helper function in a suitable location that can map from a reg to its decl, then check if it's a parameter. Given that flags in the main rtl structures are generally scarce, I think the latter is a better solution given how rarely we need to make this distinction. I used an rtl flag because I could make one available. Structures on the side always make me nervous, they tend to be fragile and hard to update. It's unfortunate that this P1 regression was left languishing, half analyzed in our tree for 6+ months ;( Not true: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00847.html It's unfortunate that the patch was never reviewed.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #9 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-01-08 17:39:23 UTC --- I think reverting would be backward - we should clearly move forward. One way forward is to simply declare PCH unsupported with stabs. This is what I think we should do about this bug. The problem isn't limited to PCH, it also happens with other delayed outputs. For instance, there's stabs info for symbols not emitted at all by cgraphunit, and debug info isn't emitted at all with LTO. The DWARF-to-*out debug translator should be the way forward IMHO. It'd simplify many things in GCC internals. I might give it a stab (no pun...) for GCC 4.9, but for GCC 4.8 I really don't see any way to fix this issue.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #11 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-01-08 18:04:09 UTC --- All that to avoid one #include output.h in one file? Is that one little thing really the only change you see? I see a different picture. The change is a major step in the direction of making a clear cut between the middle/back end and the front ends. A front end should not output assembly, period, if we want the front ends to become separate libraries, in the long run, that can be used by external tools (static checkers, IDEs, etc.) like clang. For the long term, this is IMHO the only viable solution for keeping the GCC front ends relevant. The change also allows the compiler to open the assembler file in write-only mode and to open it only after the front end is done. My plan is to postponed it even further: for GCC 4.9 I'd like to work on streaming slim LTO objects directly to a .o file, without going through an assembler file at all (this is relatively simple for ELF targets). Finally, the change also simplifies the PCH mechanism further. If we're ever going to replace PCH-as-a-memory-dump with something streamed, we'll have to make an effort at only streaming IR objects, not assembler output. Had I known this change would break stabs like this, I'd obviously have tried to solve that problem first. But to back out the change now would be a mistake. Nobody is going to fix those *out.c back ends, as you very well know.
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #10 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-12-07 10:16:49 UTC --- On Fri, Dec 7, 2012 at 11:11 AM, izamyatin at gmail dot com wrote: Looks like there is some garbage in BLOCK_FOR_INSN field for barrier instruction... A BARRIER doesn't even have a BLOCK_FOR_INSN. It's not an insn, after all. Where/how do you end up looking at BLOCK_FOR_INSN for a BARRIER?
[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640 --- Comment #16 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-09-07 19:07:27 UTC --- Any progress on the real solution? If not, can you install the branch fix on trunk? Thx. I think I already mentioned before that the branch fix is the only real fix I can think of. The problem has been aggravated by the visibility machinery, it depends on having a pending-externs list.
[Bug middle-end/54364] Tail call jumps not threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54364 --- Comment #2 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-24 12:01:40 UTC --- With -O2 this is cleaned up by bb-reorder.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #12 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-23 07:56:13 UTC --- The patch is of couse a big hammer because it has a cost, but IMHO it still makes sense. I'm not convinced. GCC has always detected this kind of loop (even the old non-cfg loop code recognizes this kind of loop) and it has never caused any problems before your patch to keep the loop structure up-to-date. To me, this means that the fix should be in the loop updating, not in abandoning a decades-old behavior of the compiler.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #15 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot
com 2012-08-23 08:49:32 UTC ---
On Thu, Aug 23, 2012 at 10:07 AM, rguenther at suse dot de
gcc-bugzi...@gcc.gnu.org wrote:
Already the input to tracer is wrong in that we have lost
a loop, the one with abnormal path from latch to header (which
we _do_ reject during loop discovery!).
But this isn't a natural loop. It's an irreducible loop with loop
entries in basic block 3 and basic block 4 (in the pre-tracer CFG from
comment #7) and loop discovery doesn't record irreducible loop.
What tracer does here is known as node splitting to make an
irreducible region reducible. I don't think it's a
intentional/conscious node splitting but tracer does have the effect
of node splitting. After tracer, the loop with bbs {4,5,3} is a
natural loop and the CFG is reducible.
So what happens is
that we turn this loop into one that would have been recognized,
swap header and latch and thus get the abnormal edge to a tolerated
place (header to latch). That inconsistency is what my patch tries
to address (another way would be to simply allow EH/abnormal
latch - header edges as well).
But with your patch we'd also reject all already reducible loops if
there are only paths with one or more abnormal edges from the loop
header to the latch. That is more conservative than necessary. Also,
AFAIU, with your patch we'd reduce loops with a finally block
(something like
for(;;){try{...maybe_throw;...;if(...)break;}finally{...}}) because
all paths to the loop latch would go through the finally block via EH
edges.
but it does not add bb3 to loop1, nor zero out its latch
and setting may-have-multiple-latches.
That, to me, is the bug we should try to solve here.
The cfghook
only takes care of updating the loop structure with
respect to the _new_ basic block but does not consider
that the old one magically becomes part of a loop.
I think it may be possible to construct a test case just like this one
with an initially irreducible CFG that tracer makes reducible.
Anyway, consider this test case, which is the pre-tracer CFG but
without abnormal edges:
void do_something_1 (void);
void do_something_2 (void);
int some_cond (void);
void make_bb_non_empty ();
void
foo (void)
{
bb2:
make_bb_non_empty ();
goto bb3;
bb4:
switch (some_cond ())
{
case 1:
goto bb3;
case 2:
goto bb5;
default:
goto bb6;
}
bb3:
do_something_1 ();
goto bb4;
bb5:
do_something_2 ();
goto bb4;
bb6:
return;
}
This gives the following CFG in the .129t.cddce2 dump:
; 3 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7
;;
;; Loop 1
;; header 5, latch 4
;; depth 1, outer 0
;; nodes: 5 4 3 6
;;
;; Loop 2
;; header 3, latch 6
;; depth 2, outer 1
;; nodes: 3 6
ENTRY
|
V
|
2(0)
|
|
V
|
| +--4(1)-+
| | |
| V ^
| | |
| | +
| + /
| | /
5(1)--3(2)--6(2)-+
/\ |
/ +-+
/
|
V
|
7(0)
|
EXIT
So now the loop {5,4,3,6} is detected, even though the CFG is
basically the same as the pre-tracer one from comment #7 (only
difference is that the critical edge 3,5 in the above CFG is split
to give basic block 4.
Makes me wonder why the loop isn't recognized in the original test case...
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #29 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-22 17:33:00 UTC --- I thought that loop header copying wouldn't need to insert new PHI nodes and thus can do with TODO_update_ssa_no_phi if we are in loop-closed SSA form, but appearantly that is not the case (I didn't inverstigate further here, but possibly that's just because virtual operands are not in loop-closed SSA form). I'll experiment with VOPs in LC-SSA.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #58 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-21 13:56:27 UTC --- FWIW, I think all patches addressing parts of this bug are candidates for back-porting to release branches. They are all almost trivial.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #50 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot
com 2012-08-16 13:55:40 UTC ---
On Thu, Aug 16, 2012 at 2:10 PM, rguenth at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
bitmap stats are confusing because they show leaks for bitmaps we free
by releasing their obstack. DF and PTA bitmaps are largest.
The bitmap obstack stats are not very reliable anyway, I think. I've
been using my own stats for this (with a size_t version of
obstack_memory_used:
+static size_t
+obstack_memory_used2 (struct obstack *h)
+{
+ struct _obstack_chunk* lp;
+ size_t nbytes = 0;
+
+ for (lp = h-chunk; lp != 0; lp = lp-prev)
+{
+ nbytes += (size_t) (lp-limit - (char *) lp);
+}
+ return nbytes;
+}
+
so that also the freed bitmap elements are counted). With that, you
can show that the reg_obstack and bitmap_default_obstack grow up to
several GB that isn't released between passes. An added problem is
that IRA puts its bitmap on its own obstack (as it should, really) but
that means the 3GB of free elements on the reg_obstack and
bitmap_default_obstack remain unused. So on the machine I use for
testing (cfarm gcc17), the memory footprint is reduced by 2GB (~25%)
with this hack:
Index: ira.c
===
--- ira.c (revision 190442)
+++ ira.c (working copy)
@@ -4132,6 +4132,12 @@
int max_regno_before_ira, ira_max_point_before_emit;
int rebuild_p;
+ /* There shouldn't be anything on these obstacks. */
+ bitmap_obstack_release (NULL);
+ bitmap_obstack_initialize (NULL);
+ bitmap_obstack_release (reg_obstack);
+ bitmap_obstack_initialize (reg_obstack);
+
if (flag_caller_saves)
init_caller_save ();
There is in general a lot of BITMAP_ALLOC(NULL) abuse in the compiler.
I have patches to address the cases in tree-ssa-live.c and dse.c, and
I intend to look at the tree-ssa-ter and cfgexpand cases this weekend.
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #20 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-06 09:09:02 UTC --- On Mon, Aug 6, 2012 at 10:45 AM, rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: Ick, I suppose similar issues exist on the tree level for passes that think that memory / compile-time usage O(number-of-ssa-names or basic-blocks) is ok (and I suppose it really _is_ ok ...?) I think this is OK, yes. In general, anything linear in some measure of the function should be OK. NB, this thing in ifcvt is *not* O(max_reg_num()) but O(max_reg_num()*n_basic_blocks). I suspect that in the tree optimizers, a non-linear issue exists for rewriting into loop-closed SSA form. It looks like it is O(num_ssa_names*n_basic_blocks). I'm trying to confirm that (in my evening free time, so don't hold your breath ;-).
[Bug tree-optimization/53986] missing vrp on bit-mask test, LSHIFT_EXPR not handled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986 --- Comment #7 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-05 13:53:30 UTC --- On Sun, Aug 5, 2012 at 3:32 PM, vries at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: I think you forgot the cast to unsigned after the add that represents the currently generated code: It would seem so... Anyway, I am quite sure to remember correctly that I had the unsigned before the add, and it caused bootstrap or test issues. But as always, patches welcome :-)
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #19 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-07-26 19:44:59 UTC --- Dodji, please see http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01204.html
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #8 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-07-24 08:16:01 UTC --- (In reply to comment #7) I don't think it's really called from there. It should be called from gt_pch_save. gt_pch_nx_line_maps only registers the function (for pointer rewriting, AFAIU).
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #11 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-07-24 09:41:18 UTC --- Err, isn't the GTY annotation in as y1. x0 is the spelling location for the argument token 1, and x2 is the spelling location for the argument token 2. */ source_location * GTY((length (2 * %h.n_tokens))) macro_locations; simply pointless? I don't think so. You still want to pointer-rewrite it if you output a PCH.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #13 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-07-24 10:03:05 UTC --- On Tue, Jul 24, 2012 at 11:42 AM, rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: The pointer to the array, but not the array elements. So it's pointless to know the length and souce_location * macro_locations; should still rewrite the pointer itself, no? Hmm. I'm not sure. Without the annotation, how does the PCH machinery know how long that array is? OTOH there isn't anything else, other than those dead loops, that looks at h.n_tokens. Perhaps there should be a warning from gengtype if the length attribute is applied to a scalar type.
[Bug pch/54042] always create and use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54042 --- Comment #3 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-07-20 16:23:33 UTC --- On Fri, Jul 20, 2012 at 5:36 PM, pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-20 15:36:11 UTC --- PPH might be already supporting this though. No, read the paper linked to by this message: http://gcc.gnu.org/ml/gcc/2012-05/msg00335.html PPH development is paused (perhaps abandoned).
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #12 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-07-19 18:11:30 UTC --- On Thu, Jul 19, 2012 at 7:50 PM, amonakov at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: I wonder how this bug managed to stay latent all these years :) This is very simple: Nobody uses ia64 ;-)
[Bug java/52730] Java front end emits assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52730 --- Comment #5 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-03-26 21:31:44 UTC --- Yes, I've reverted that patch for the time being.
[Bug tree-optimization/43940] DOM doesn't propagate constants properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940 --- Comment #7 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-03-19 09:51:41 UTC --- --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-19 09:34:58 UTC --- I think this was fixed by 2012-02-29 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/52424 * tree-ssa-dom.c (dom_opt_leave_block): Push a marker before calling dom_thread_across_edge. I think it was fixed by ifcombine. But in any case, yes, resolved AFAIC.
[Bug middle-end/45273] [4.4/4.5/4.6/4.7 Regression] The compiler depends on the host double (-fprofile-corection only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273 --- Comment #8 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-01-20 19:17:53 UTC --- Is there already a meta bug for patches queued for 4.8?
[Bug rtl-optimization/51495] [4.7 Regression] ICE: in force_nonfallthru_and_redirect, at cfgrtl.c:1171 with computed goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51495 --- Comment #3 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2011-12-12 14:09:12 UTC --- Untested fix. Wouldn't that fix make this operation O(E^2)?
[Bug bootstrap/51388] Configure failure to detect unsupported warning options for non-bootstrap builds (including cross builds)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388 --- Comment #3 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2011-12-02 14:59:37 UTC --- On Fri, Dec 2, 2011 at 3:51 PM, rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: I see gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG cc1: error: unrecognized command line option -Wno-narrowing with FSF GCC 4.3.6. So, are you sure this isn't behavior caused by vendor patches? (openSUSE GCC 4.3 also works) What do you see with gcc-4.3 -c -Wno-narrowing t.c? FWIW this is Debian GCC 4.3.2-1.1 on gcc17.
[Bug rtl-optimization/48389] [4.5/4.6 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #14 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2011-04-09 10:08:57 UTC --- On Fri, Apr 8, 2011 at 1:38 PM, matz at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-04-08 11:37:59 UTC --- I was asking what specifically doesn't work. I.e. why the changes to cfgbuild were necessary. I'm not so dense to not understand that it doesn't work. But you are so dense to not look at all information in the PR? :-P I had made PR48486 blocking this one. It explains what the cfgbuild.c changes were supposed to resolve.
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #9 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2011-04-07 21:28:12 UTC --- --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-04-07 15:38:38 UTC --- Hmpf, what doesn't work with just moving the rebuild_jump_labels call? The testcase works, but I haven't tried the testsuite. Because it should theoretically work. Yes, it should, but it does not. Why do you think I'm meddling with cfgbuild.c? The EDGE_EXECUTABLE thing was needed to pass a verify_flow_info() called from commit_edge_insertions() but it's probably not necessary anymore now that I commit edge inserts manually (to work around other verify_flow_info() errors). FWIW the patch doesn't bootstrap, and I'm still trying to figure out what the problem is now.
[Bug rtl-optimization/47216] [4.6 Regression] gcc.dg/torture/pr43360.c FAILs with -O -fPIC -fgcse -fgcse-sm -fnon-call-exceptions -fno-tree-dse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47216 --- Comment #7 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2011-01-18 21:42:50 UTC --- Resolved alright -- but including tree-flow.h in emit-rtl.c??? :-(
