[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6

2010-09-07 Thread dberlin at dberlin dot org
--- Comment #37 from dberlin at gcc dot gnu dot org 2010-09-07 22:50 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 You should have shell access, do you not? On Tue, Sep 7, 2010 at 2:11 PM, LpSolit at netscape dot net gcc-bugzi...@gcc.gnu.org wrote: ---

[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6

2010-07-19 Thread dberlin at dberlin dot org
--- Comment #28 from dberlin at gcc dot gnu dot org 2010-07-19 12:00 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 On Thu, Jul 15, 2010 at 7:04 PM, LpSolit at netscape dot net gcc-bugzi...@gcc.gnu.org wrote: --- Comment #27 from LpSolit at netscape dot net  

[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6

2010-03-30 Thread dberlin at dberlin dot org
--- Comment #25 from dberlin at gcc dot gnu dot org 2010-03-30 23:18 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 Note: I have no urge or time to upgrade gcc's bugzilla anymore. If ya'll want to work on it, i'm happy to give you all the info i have and get you shell

[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5

2010-02-11 Thread dberlin at dberlin dot org
--- Comment #19 from dberlin at gcc dot gnu dot org 2010-02-11 20:44 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 It has the security patch ;) None of this would have been a big deal if it hadn't taken bugzilla 10 years to decide on custom fields ;) THe main

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

2009-09-06 Thread dberlin at dberlin dot org
--- Comment #14 from dberlin at gcc dot gnu dot org 2009-09-06 14:15 --- Subject: Re: [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419 On Sun, Sep 6, 2009 at 8:41 AM, rguenth at gcc dot gnu dot orggcc-bugzi...@gcc.gnu.org wrote: --- Comment #12 from

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

2009-09-06 Thread dberlin at dberlin dot org
--- Comment #16 from dberlin at gcc dot gnu dot org 2009-09-06 14:19 --- Subject: Re: [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419 On Sun, Sep 6, 2009 at 8:50 AM, rguenth at gcc dot gnu dot orggcc-bugzi...@gcc.gnu.org wrote: --- Comment #13 from

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-07-15 Thread dberlin at dberlin dot org
--- Comment #22 from dberlin at gcc dot gnu dot org 2009-07-15 13:37 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 Phi uses can be in the maximum set as long as they are not phi's themselves. There is a comment above

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-07-15 Thread dberlin at dberlin dot org
--- Comment #23 from dberlin at gcc dot gnu dot org 2009-07-15 13:46 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 a_1 shouldn't be in the maximal set. If it is, that's a bug. The history here: We didn't use to have

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-18 Thread dberlin at dberlin dot org
--- Comment #15 from dberlin at gcc dot gnu dot org 2009-06-18 15:48 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 No, still trying to figure it out. It's quite tricky. On Thu, Jun 18, 2009 at 11:38 AM, rguenth at

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

2009-06-03 Thread dberlin at dberlin dot org
--- Comment #13 from dberlin at gcc dot gnu dot org 2009-06-03 15:16 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 Hmmm, clean should only have to check set1 and set2, not AVAIL_OUT. I'm not sure why it looks at

[Bug tree-optimization/21485] [4.3/4.4/4.5 Regression] missed load PRE, PRE makes i?86 suck

2009-04-21 Thread dberlin at dberlin dot org
--- Comment #41 from dberlin at gcc dot gnu dot org 2009-04-21 13:24 --- Subject: Re: [4.3/4.4/4.5 Regression] missed load PRE, PRE makes i?86 suck Fernando was an intern of mine, and while his algorithm is a great algorithm, AFAIK he hasn't gotten better code out of it than

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

2009-02-21 Thread dberlin at dberlin dot org
--- Comment #106 from dberlin at gcc dot gnu dot org 2009-02-21 22:34 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines Right. Basically, the value numbering PRE uses as a pre-pass is known as SCCVN. It value numbers by doing a depth first

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

2009-02-20 Thread dberlin at dberlin dot org
--- Comment #101 from dberlin at gcc dot gnu dot org 2009-02-21 04:13 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines PRE already gives up on this testcase, at least on my computer, and takes no memory. All of the memory here is being eaten

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

2009-02-15 Thread dberlin at dberlin dot org
--- Comment #96 from dberlin at gcc dot gnu dot org 2009-02-16 02:07 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines Uh, it's most certainly disabled on testcases like his. look at is_too_expensive in gcse.c This is in fact done because LCM

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

2009-02-14 Thread dberlin at dberlin dot org
--- Comment #94 from dberlin at gcc dot gnu dot org 2009-02-14 23:06 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines One of the reasons LCM in RTL is so slow is because it uses a crappy iteration order. With the right iteration order, it

[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE

2009-02-05 Thread dberlin at dberlin dot org
--- Comment #17 from dberlin at gcc dot gnu dot org 2009-02-05 16:41 --- Subject: Re: [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE Ugh. It might make sense to just replace the hash table implementation we use with something better (simple power of 2, key-value

[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE

2009-02-05 Thread dberlin at dberlin dot org
--- Comment #18 from dberlin at gcc dot gnu dot org 2009-02-05 17:43 --- Subject: Re: [4.3/4.4 Regression] -fprofile-generate = huge SCCs for PRE My hacking will seriously improve this, since it doesn't iterate over pieces of the SCC that aren't changing (which often is most

[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong

2009-02-04 Thread dberlin at dberlin dot org
2009-02-04 09:35 --- Subject: Re: PTA constraint processing for *x = y is wrong On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote: --- Comment #7 from dberlin at gcc dot gnu dot org 2009-02-04 00:29 --- Subject: Re: PTA constraint processing for *x = y is wrong

[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong

2009-02-04 Thread dberlin at dberlin dot org
rguenther at suse dot de 2009-02-04 16:26 --- Subject: Re: [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote: --- Comment #13 from dberlin at gcc dot gnu dot org 2009-02-04 16:09 --- Subject: Re: PTA

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

2009-02-04 Thread dberlin at dberlin dot org
--- Comment #83 from dberlin at gcc dot gnu dot org 2009-02-04 18:24 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines These numbers claim a leak of the graph-preds bitmap (and related bitmaps) which are quite clearly freed all the time. These

[Bug tree-optimization/39100] [4.4 Regression] -fstrict-aliasing miscompilation

2009-02-04 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2009-02-04 21:16 --- Subject: Re: [4.4 Regression] -fstrict-aliasing miscompilation On Wed, Feb 4, 2009 at 3:59 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from rguenth at gcc dot

[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong

2009-02-03 Thread dberlin at dberlin dot org
--- Comment #5 from dberlin at gcc dot gnu dot org 2009-02-03 14:16 --- Subject: Re: PTA constraint processing for *x = y is wrong There used to be a *ANYTHING = ANYTHING constraint + ANYTHING containing all the variables pointing to ANYTHING that would have taken care of

[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong

2009-02-03 Thread dberlin at dberlin dot org
2009-02-03 14:24 --- Subject: Re: PTA constraint processing for *x = y is wrong On Tue, 3 Feb 2009, dberlin at dberlin dot org wrote: Subject: Re: PTA constraint processing for *x = y is wrong There used to be a *ANYTHING = ANYTHING constraint + ANYTHING containing all

[Bug middle-end/38932] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398

2009-01-22 Thread dberlin at dberlin dot org
--- Comment #11 from dberlin at gcc dot gnu dot org 2009-01-22 17:12 --- Subject: Re: [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 Uh, well, that would be tricky since none of this code still exists in 4.4.0 On Thu, Jan 22, 2009 at 11:09 AM, hjl dot tools

[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769

2009-01-21 Thread dberlin at dberlin dot org
--- Comment #2 from dberlin at gcc dot gnu dot org 2009-01-21 14:09 --- Subject: Re: [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769 names should be self-leaders. Sounds like a set bitmap messup somewhere or an equality function gone bad or

[Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop

2009-01-16 Thread dberlin at dberlin dot org
--- Comment #8 from dberlin at gcc dot gnu dot org 2009-01-16 20:48 --- Subject: Re: [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop Hmmm. The only way you could get the CFG to represent that any call may exit would be to calls terminate bb's and have

[Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop

2009-01-16 Thread dberlin at dberlin dot org
rguenther at suse dot de 2009-01-16 21:01 --- Subject: Re: [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop On Fri, 16 Jan 2009, dberlin at dberlin dot org wrote: Subject: Re: [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop

[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars

2009-01-13 Thread dberlin at dberlin dot org
--- Comment #3 from dberlin at gcc dot gnu dot org 2009-01-13 18:42 --- Subject: Re: points-to result wrong for reads from call-clobbered vars Interesting. I have emailed some others for their thoughts. One way to eliminate this bug would be to mark the entire structure as

[Bug tree-optimization/38723] default definitions not in avail_out

2009-01-04 Thread dberlin at dberlin dot org
--- Comment #2 from dberlin at gcc dot gnu dot org 2009-01-04 22:35 --- Subject: Re: New: default definitions not in avail_out At one time we pretended they were defined in the entry block, and IIRC, it worked out okay. Dunno what happened to this :) On Sun, Jan 4, 2009 at 1:40 PM,

[Bug middle-end/38533] [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times

2008-12-16 Thread dberlin at dberlin dot org
--- Comment #4 from dberlin at gcc dot gnu dot org 2008-12-16 17:00 --- Subject: Re: [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register pressure several times Yes, that looks like a bug. There are also numerous ways in which the placement can be improved. A few people had

[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization

2008-12-04 Thread dberlin at dberlin dot org
--- Comment #4 from dberlin at gcc dot gnu dot org 2008-12-04 17:14 --- Subject: Re: TreeSSA-PRE load after store misoptimization That would be incorrect. Partial partial (Partial antic, Partial Avail). PRE is necessary to catch all the cases LCM does (and RTL PRE is LCM based). LCM

[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization

2008-12-04 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2008-12-04 17:35 --- Subject: Re: TreeSSA-PRE load after store misoptimization Yes, i'm aware, but again, that is because my recollection is doing partial antic partial avail with lifetime optimality requires code placement that we

[Bug tree-optimization/23286] missed fully redundant expression

2008-11-23 Thread dberlin at dberlin dot org
--- Comment #22 from dberlin at gcc dot gnu dot org 2008-11-23 18:30 --- Subject: Re: missed fully redundant expression Sinking fits into the reverse framework. Apparently the SSUPRE person plans on submitting when 4.5 opens, and you can fit sinking frameworks into there. On Sun,

[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang

2008-11-02 Thread dberlin at dberlin dot org
--- Comment #8 from dberlin at gcc dot gnu dot org 2008-11-02 20:53 --- Subject: Re: [4.4 Regression] excessive memory consumption - possible hang On Sun, Nov 2, 2008 at 7:04 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from rguenth at gcc dot gnu

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

2008-10-20 Thread dberlin at dberlin dot org
--- Comment #27 from dberlin at gcc dot gnu dot org 2008-10-20 16:22 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math Err, works for me with -O2 -ffast-math Replaced D.1587_48 - D.1591_50 with prephitmp.17_60 in D.1600_23 = D.1587_48 - D.1591_50;

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

2008-10-16 Thread dberlin at dberlin dot org
--- Comment #25 from dberlin at gcc dot gnu dot org 2008-10-16 23:30 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math I fixed the PRE issue with builtin_pow here. :) On Wed, Oct 15, 2008 at 2:50 PM, dberlin at dberlin dot org [EMAIL PROTECTED] wrote

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

2008-10-15 Thread dberlin at dberlin dot org
--- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math It already does (I fixed that recently), but we only phi-translate during insertion and we don't insert for that case, as

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

2008-10-15 Thread dberlin at dberlin dot org
--- Comment #18 from dberlin at gcc dot gnu dot org 2008-10-15 13:06 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math Making PRE do this is somewhat trivial. Just extend fully_constant_expression to fold builtins, like it used to, and it should just

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

2008-10-15 Thread dberlin at dberlin dot org
answer for -O1 -ffast-math On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote: --- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math It already does (I fixed that recently

[Bug tree-optimization/36830] [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb

2008-07-27 Thread dberlin at dberlin dot org
--- Comment #10 from dberlin at gcc dot gnu dot org 2008-07-27 15:37 --- Subject: Re: [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb No, it doesn't. Even if the op isn't hashed, it is still compared for in vn_reference_op_eq, so at worst the non-hashing will make it

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

2008-07-25 Thread dberlin at dberlin dot org
--- Comment #20 from dberlin at gcc dot gnu dot org 2008-07-25 07:11 --- Subject: Re: [4.4 Regression] I/Os hang at rev. 137631 on darwin9 Yes. On Thu, Jul 24, 2008 at 11:56 PM, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #19 from dominiq at lps dot

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

2008-07-25 Thread dberlin at dberlin dot org
--- Comment #23 from dberlin at gcc dot gnu dot org 2008-07-25 08:11 --- Subject: Re: [4.4 Regression] I/Os hang at rev. 137631 on darwin9 The first. For various reasons, get_external_unit in io/unit.c was being miscompiled. On Fri, Jul 25, 2008 at 12:26 AM, dominiq at lps dot ens

[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault

2008-07-20 Thread dberlin at dberlin dot org
--- Comment #8 from dberlin at gcc dot gnu dot org 2008-07-20 14:03 --- Subject: Re: [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault I tried i686-darwin and it work for me too. I'll try cross to ppc-darwin. On Sun, Jul 20, 2008 at 7:16 AM, rguenth at gcc

[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault

2008-07-20 Thread dberlin at dberlin dot org
--- Comment #18 from dberlin at gcc dot gnu dot org 2008-07-20 21:13 --- Subject: Re: [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault All the blocks we have marked in the bitmap to eh cleanup exist when we pass them to tree_purge_dead_eh_edges.

[Bug bootstrap/36864] [4.4 Regression] Yet another bootstrap failure on i686-apple-darwin9

2008-07-19 Thread dberlin at dberlin dot org
--- Comment #7 from dberlin at gcc dot gnu dot org 2008-07-19 12:33 --- Subject: Re: [4.4 Regression] Yet another bootstrap failure on i686-apple-darwin9 this is not a correct understanding, we are just testing what is the best fix. I've posted a patch to bandaid this while we test

[Bug bootstrap/36864] [4.4 Regression] Yet another bootstrap failure on i686-apple-darwin9

2008-07-19 Thread dberlin at dberlin dot org
--- Comment #8 from dberlin at gcc dot gnu dot org 2008-07-19 12:36 --- Subject: Re: [4.4 Regression] Yet another bootstrap failure on i686-apple-darwin9 I'll attach the patch here in case you want to test it first. On Sat, Jul 19, 2008 at 8:33 AM, dberlin at dberlin dot org [EMAIL

[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures

2008-07-11 Thread dberlin at dberlin dot org
--- Comment #3 from dberlin at gcc dot gnu dot org 2008-07-11 19:15 --- Subject: Re: [4.4 Regression] Revision 137631 causes many failures I am working on the one x86_64 specific failure first :) On Fri, Jul 11, 2008 at 2:19 PM, hjl dot tools at gmail dot com [EMAIL PROTECTED]

[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault

2008-07-08 Thread dberlin at dberlin dot org
--- Comment #1 from dberlin at gcc dot gnu dot org 2008-07-09 01:56 --- Subject: Re: [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault need .ii file at least. On Tue, Jul 8, 2008 at 9:15 PM, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --

[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic

2008-06-12 Thread dberlin at dberlin dot org
--- Comment #9 from dberlin at gcc dot gnu dot org 2008-06-12 14:51 --- Subject: Re: [4.3 Regression] ICE in compute_antic The assert is there because often when people break PRE, it goes into infinite loops due to non-convergence, and eats all memory and CPU very very very quickly.

[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898

2008-02-16 Thread dberlin at dberlin dot org
--- Comment #20 from dberlin at gcc dot gnu dot org 2008-02-16 14:56 --- Subject: Re: [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898 So, there are better SCC algorithms. In particular, Nuutilla's algorithm will avoid placing a bunch of nodes on the stack

[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.

2008-01-25 Thread dberlin at dberlin dot org
--- Comment #9 from dberlin at gcc dot gnu dot org 2008-01-25 16:51 --- Subject: Re: [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile. On 25 Jan 2008 16:40:54 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: I think we are also

[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression

2008-01-12 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2008-01-12 19:33 --- Subject: Re: [4.3 Regression] ICE in find_or_generate_expression On 12 Jan 2008 19:13:56 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from rguenth at gcc dot gnu dot org

[Bug tree-optimization/34677] PREs insert_fake_stores is mostly useless

2008-01-04 Thread dberlin at dberlin dot org
--- Comment #4 from dberlin at gcc dot gnu dot org 2008-01-04 17:31 --- Subject: Re: PREs insert_fake_stores is mostly useless FRE will handle DECL's, and VN will value number them. I've made small attempts at make PRE work with globals, but i'm lazy and haven't done it for real yet

[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext

2007-11-22 Thread dberlin at dberlin dot org
--- Comment #13 from dberlin at gcc dot gnu dot org 2007-11-22 15:35 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On 22 Nov 2007 14:03:35 -, matz at suse dot de [EMAIL PROTECTED] wrote: --- Comment #9 from matz at suse dot de 2007-11-22 14:03 --- Subject:

[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext

2007-11-22 Thread dberlin at dberlin dot org
--- Comment #18 from dberlin at gcc dot gnu dot org 2007-11-22 23:02 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On 22 Nov 2007 22:51:12 -, matz at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #17 from matz at gcc dot gnu dot org 2007-11-22 22:51

[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext

2007-11-21 Thread dberlin at dberlin dot org
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-11-22 04:48 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On 22 Nov 2007 04:26:57 -, matz at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from matz at gcc dot gnu dot org 2007-11-22 04:26

[Bug tree-optimization/26854] Inordinate compile times on large routines

2007-11-14 Thread dberlin at dberlin dot org
--- Comment #33 from dberlin at gcc dot gnu dot org 2007-11-14 16:57 --- Subject: Re: Inordinate compile times on large routines On 14 Nov 2007 13:37:54 -, lucier at math dot purdue dot edu [EMAIL PROTECTED] wrote: --- Comment #31 from lucier at math dot purdue dot edu

[Bug tree-optimization/28868] [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have the same arguments

2007-11-04 Thread dberlin at dberlin dot org
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-11-04 19:24 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have the same arguments On 4 Nov 2007 15:45:59 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #10 from

[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE

2007-11-01 Thread dberlin at dberlin dot org
--- Comment #12 from dberlin at gcc dot gnu dot org 2007-11-01 21:24 --- Subject: Re: [4.3 Regression] Exponential time behavior in PRE Yes, the heuristics can sometimes generate a very large number of copies to eliminate a single redundancy. This is jsut the way the standard PRE

[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph

2007-10-31 Thread dberlin at dberlin dot org
--- Comment #16 from dberlin at gcc dot gnu dot org 2007-10-31 14:22 --- Subject: Re: [4.2 Regression] memory hog in solve_graph On 31 Oct 2007 13:07:57 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #15 from rguenth at gcc dot gnu dot org

[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE

2007-10-20 Thread dberlin at dberlin dot org
--- Comment #8 from dberlin at gcc dot gnu dot org 2007-10-20 20:49 --- Subject: Re: [4.3 Regression] Exponential time behavior in PRE We may just want to disable PPRE of constants entirely :) On 20 Oct 2007 10:14:53 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote:

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

2007-10-17 Thread dberlin at dberlin dot org
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-10-17 17:41 --- Subject: Re: [4.3 Regression] Revision 126326 causes 12% slowdown On 17 Oct 2007 16:59:25 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #13 from pinskia at gcc dot gnu dot org

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

2007-10-10 Thread dberlin at dberlin dot org
--- Comment #34 from dberlin at gcc dot gnu dot org 2007-10-10 17:43 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop On 10 Oct 2007 08:58:00 -, steven at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #33 from steven at gcc dot

[Bug c++/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2

2007-10-01 Thread dberlin at dberlin dot org
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-10-01 21:07 --- Subject: Re: [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2 I'm not fixing this until someone can tell me what exactly is going wrong. There have been *so* many

[Bug tree-optimization/33508] [4.3 Regression] tree struct aliasing goes into a loop marking call clobbers.

2007-09-20 Thread dberlin at dberlin dot org
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-09-20 15:12 --- Subject: Re: [4.3 Regression] tree struct aliasing goes into a loop marking call clobbers. On 20 Sep 2007 13:52:11 -, ramana dot radhakrishnan at celunite dot com [EMAIL PROTECTED] wrote: --- Comment #6

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

2007-09-11 Thread dberlin at dberlin dot org
--- Comment #45 from dberlin at gcc dot gnu dot org 2007-09-11 12:58 --- Subject: Re: [4.2/4.3 Regression] points-to analysis slow and memory hungry Uh, it's not slow anymore since I committed the patch last month. On 11 Sep 2007 10:59:31 -, giovannibajo at libero dot it [EMAIL

[Bug tree-optimization/30052] [4.2/4.3 Regression] points-to analysis slow and memory hungry

2007-09-11 Thread dberlin at dberlin dot org
--- Comment #47 from dberlin at gcc dot gnu dot org 2007-09-11 19:54 --- Subject: Re: [4.2/4.3 Regression] points-to analysis slow and memory hungry On 11 Sep 2007 19:51:00 -, belyshev at depni dot sinp dot msu dot ru [EMAIL PROTECTED] wrote: --- Comment #46 from belyshev

[Bug middle-end/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite

2007-09-05 Thread dberlin at dberlin dot org
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-09-05 11:50 --- Subject: Re: [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite On 28 Aug 2007 15:58:29 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #6 from jakub

[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code

2007-09-05 Thread dberlin at dberlin dot org
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-09-05 11:51 --- Subject: Re: [4.2 Regression] -fstrict-aliasing causes skipped code On 5 Sep 2007 06:47:19 -, giovannibajo at libero dot it [EMAIL PROTECTED] wrote: --- Comment #25 from giovannibajo at libero dot it

[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE

2007-08-30 Thread dberlin at dberlin dot org
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-30 15:24 --- Subject: Re: New: Missed opportunities for vectorization due to PRE On 30 Aug 2007 02:55:17 -, spop at gcc dot gnu dot org [EMAIL PROTECTED] wrote: The following loop showing up in the top time users in

[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase

2007-08-30 Thread dberlin at dberlin dot org
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-08-30 18:24 --- Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase Log in before submitting the attachment On 30 Aug 2007 18:23:23 -, michelin60 at gmail dot com [EMAIL PROTECTED] wrote: --- Comment #1 from

[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc

2007-08-29 Thread dberlin at dberlin dot org
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-08-29 18:30 --- Subject: Re: [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc On 29 Aug 2007 15:19:10 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #21 from rguenth at

[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

2007-08-24 Thread dberlin at dberlin dot org
--- Comment #21 from dberlin at gcc dot gnu dot org 2007-08-24 15:42 --- Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop On 24 Aug 2007 15:38:58 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #20 from jakub at gcc

[Bug tree-optimization/33173] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704

2007-08-24 Thread dberlin at dberlin dot org
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-08-24 16:14 --- Subject: Re: [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4704 Accidently reversed test in tree-ssa-alias.c: find_used_portions Testing fix now. --

[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

2007-08-24 Thread dberlin at dberlin dot org
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-08-24 16:21 --- Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop On 24 Aug 2007 16:16:44 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #22 from jakub at gcc

[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

2007-08-23 Thread dberlin at dberlin dot org
--- Comment #17 from dberlin at gcc dot gnu dot org 2007-08-23 13:45 --- Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop On 23 Aug 2007 12:13:13 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #16 from jakub at gcc

[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c

2007-08-23 Thread dberlin at dberlin dot org
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-08-23 14:01 --- Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c On 23 Aug 2007 13:55:21 -, bonzini at gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from bonzini at gnu dot org 2007-08-23

[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c

2007-08-23 Thread dberlin at dberlin dot org
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-08-23 14:05 --- Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c On 8/23/07, Daniel Berlin [EMAIL PROTECTED] wrote: On 23 Aug 2007 13:55:21 -, bonzini at gnu dot org [EMAIL PROTECTED] wrote:

[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c

2007-08-23 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-08-23 14:09 --- Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c Yes, you are right. I wasn't thinking clearly --- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 --- Hmmm, a store into an

[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

2007-08-23 Thread dberlin at dberlin dot org
dot com 2007-08-23 14:49 --- Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop On Thu, Aug 23, 2007 at 01:45:11PM -, dberlin at dberlin dot org wrote: If you take address of the whole struct rather than some specific field and that address

[Bug middle-end/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE

2007-08-16 Thread dberlin at dberlin dot org
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-16 17:37 --- Subject: Re: [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE Yeah, we either need to remove salias, or force create an empty may_alias pass that returns TODO_may_alias but does nothing else. I'm not

[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp

2007-07-26 Thread dberlin at dberlin dot org
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-26 18:22 --- Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp Also, it requires boost :) On 7/26/07, Daniel Berlin [EMAIL PROTECTED] wrote: Preprocessed source please. I don't make installed

[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp

2007-07-26 Thread dberlin at dberlin dot org
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-26 18:21 --- Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp Preprocessed source please. I don't make installed versions of the compiler to play with :) On 25 Jul 2007 11:46:35 -, rguenth at

[Bug c++/32900] [4.2/4.3 regression] compile time and memory regression

2007-07-25 Thread dberlin at dberlin dot org
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-25 22:40 --- Subject: Re: New: [4.2/4.3 regression] compile time and memory regression Points-to memory with these is almost nothing, so don't look at meef. It looks like size goes up for each function and is not fully

[Bug tree-optimization/32746] [4.3 Regression] tree-ssa-operands int.comp error

2007-07-22 Thread dberlin at dberlin dot org
--- Comment #10 from dberlin at gcc dot gnu dot org 2007-07-22 15:42 --- Subject: Re: [4.3 Regression] tree-ssa-operands int.comp error I already submitted a patch for this (see my followup to HP that fixes valid_gimple_expression_p). As soon as i can bootstrap on darwin, i will

[Bug tree-optimization/32199] jc1: out of memory allocating 4072 bytes after a total of 805021000 bytes

2007-07-16 Thread dberlin at dberlin dot org
--- Comment #8 from dberlin at gcc dot gnu dot org 2007-07-16 13:41 --- Subject: Re: jc1: out of memory allocating 4072 bytes after a total of 805021000 bytes Hi guys, can you check whether the 32723 fix that was just checked in fixes this? I believe it might (it should make 4.2

[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code

2007-07-16 Thread dberlin at dberlin dot org
--- Comment #16 from dberlin at gcc dot gnu dot org 2007-07-16 13:58 --- Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code I've attached a patch you should be able to quickly backport to 4.2.1. I'm still testing it against mainline right now. On 16 Jul 2007

[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code

2007-07-16 Thread dberlin at dberlin dot org
--- Comment #20 from dberlin at gcc dot gnu dot org 2007-07-16 22:29 --- Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code Oh, for 4.2 you need to add make_constraint_to_escaped_var On 16 Jul 2007 15:51:44 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED]

[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-13 Thread dberlin at dberlin dot org
--- Comment #10 from dberlin at gcc dot gnu dot org 2007-07-13 16:47 --- Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 On 13 Jul 2007 15:49:03 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #9 from ebotcazou at gcc

[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-13 Thread dberlin at dberlin dot org
--- Comment #12 from dberlin at gcc dot gnu dot org 2007-07-13 17:18 --- Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 On 13 Jul 2007 17:16:27 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #11 from ebotcazou at gcc

[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-13 Thread dberlin at dberlin dot org
--- Comment #15 from dberlin at gcc dot gnu dot org 2007-07-14 02:04 --- Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 On 13 Jul 2007 20:43:37 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #14 from ebotcazou at gcc

[Bug tree-optimization/32746] [4.3 Regression] tree-ssa-operands int.comp error

2007-07-13 Thread dberlin at dberlin dot org
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-07-14 02:12 --- Subject: Re: [4.3 Regression] tree-ssa-operands int.comp error valid_gimple_expression_p claims ((struct RegisterLayout *) (char *) SimulatedRegisters)-intmask; is valid GIMPLE, when it is not. On 13 Jul 2007

[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-11 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-11 22:20 --- Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 The only way i can see this happening is if you have a truly uninitialized variable, or there is something we have missed. Does this

[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.

2007-07-10 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-10 16:59 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On 10 Jul 2007 15:32:51 -, rguenther at suse dot de [EMAIL PROTECTED] wrote: --- Comment #5 from rguenther

[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-09 Thread dberlin at dberlin dot org
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-09 18:11 --- Subject: Re: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 Uh, this assert was removed, so i don't know how it could still trigger ;) On 9 Jul 2007 17:36:22 -, ebotcazou at gcc dot gnu dot

[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-09 Thread dberlin at dberlin dot org
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-09 18:12 --- Subject: Re: New: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 Oh, this assert, sorry, i removed the other assert int his function. This means we have discovered some very very very strange

[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop

2007-07-08 Thread dberlin at dberlin dot org
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-07-08 20:40 --- Subject: Re: [4.3 regression]: revision 126369 went into an infinite loop On 8 Jul 2007 15:12:51 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #10 from hjl at lucon dot org 2007-07-08

[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop

2007-07-07 Thread dberlin at dberlin dot org
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-07 20:07 --- Subject: Re: [4.3 regression]: revision 126369 went into an infinite loop On 7 Jul 2007 19:35:01 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #6 from hjl at lucon dot org 2007-07-07

[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code

2007-07-04 Thread dberlin at dberlin dot org
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-07-04 14:16 --- Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] wrote: -- Just as an update: I have been working with

[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2

2007-07-03 Thread dberlin at dberlin dot org
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-03 15:02 --- Subject: Re: [4.3 regression] miscompilation at -O2 D.1445_69 = pretmp.53_53; storetmp.41_92 = D.1445_69; *order_p_25(D) = D.1445_69; i_71 = i_2 + 1; if (i_2 == D.1401_27) goto bb 11; else

  1   2   3   4   5   >