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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763
--- Comment #11 from stevenb.gcc at gmail dot com ---
> --- Comment #9 from Uroš Bizjak ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950
--- Comment #8 from stevenb.gcc at gmail dot com
---
> --- Comment #6 from Jakub Jelinek ---
> 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,
&g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
--- Comment #15 from stevenb.gcc at gmail dot com ---
> --- Comment #14 from Frédéric Buclin ---
> 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858
--- Comment #13 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858
--- Comment #10 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #18 from 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 c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460
--- Comment #5 from stevenb.gcc at gmail dot com
2013-02-27 21:09:55 UTC ---
> --- Comment #4 from Chris Reed 2013-02-27 12:15:52
> UTC ---
> Yes, I'm happy to address the copyright issue - the copyright disclaimer route
&
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131
--- Comment #23 from 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/co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131
--- Comment #22 from 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53948
--- Comment #6 from 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 explicitl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #11 from 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.
Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #9 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631
--- Comment #10 from 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..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640
--- Comment #16 from 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 bra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54364
--- Comment #2 from stevenb.gcc at gmail dot com
2012-08-24 12:01:40 UTC ---
With -O2 this is cleaned up by bb-reorder.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #15 from 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
wrote:
> Already the input to tracer is "wrong" in that we have "lost"
> a loop,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #12 from 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 k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #29 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #58 from 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #50 from 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
wrote:
> bitmap stats are confusing because they show leaks for bitmaps we free
> by releasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #20 from 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
wrote:
> Ick, I suppose similar issues exist on the tree level for passes that
> think that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53986
--- Comment #7 from 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
wrote:
> I think you forgot the cast to unsigned after the add that represents the
> currently generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #19 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #13 from 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
wrote:
> The pointer to the array, but not the array elements. So it's pointless
> to know the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #11 from 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 spellin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #8 from 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 (f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54042
--- Comment #3 from 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
wrote:
> --- Comment #2 from Andrew Pinski 2012-07-20
> 15:36:11 UTC ---
> PPH might b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975
--- Comment #12 from 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
wrote:
> I wonder how this bug managed to stay latent all these years :)
This is very simple: Nobody u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52730
--- Comment #5 from stevenb.gcc at gmail dot com
2012-03-26 21:31:44 UTC ---
Yes, I've reverted that patch for the time being.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
--- Comment #7 from stevenb.gcc at gmail dot com
2012-03-19 09:51:41 UTC ---
> --- Comment #6 from Richard Guenther 2012-03-19
> 09:34:58 UTC ---
> I think this was fixed by
>
> 2012-02-29 Bill Schmidt
>
> PR tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
--- Comment #8 from 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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51495
--- Comment #3 from 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)?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #3 from 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
wrote:
> I see
>
>> gcc-4.3 -c -Wno-narrowing t.c -DHAVE_ARG
> cc1: error: unrecognized comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
--- Comment #14 from 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
wrote:
> --- Comment #10 from Michael Matz 2011-04-08
> 11:37:59 UTC ---
> I was asking what spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
--- Comment #9 from stevenb.gcc at gmail dot com
2011-04-07 21:28:12 UTC ---
> --- Comment #7 from Michael Matz 2011-04-07
> 15:38:38 UTC ---
> Hmpf, what doesn't work with just moving the rebuild_jump_labels call?
> The test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47216
--- Comment #7 from stevenb.gcc at gmail dot com
2011-01-18 21:42:50 UTC ---
Resolved alright -- but including tree-flow.h in emit-rtl.c??? :-(
37 matches
Mail list logo
