--- 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
wrote:
>
>
> --- Comment #35 from LpSolit at
--- 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
wrote:
>
>
> --- Comment #27 from LpSolit at netscape dot net 2010-07-15 23:04 ---
--- 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 a
--- 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 change
--- 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
org wrote:
>
>
> --- Comment #13 from rguenth at gcc dot gnu
--- 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
org wrote:
>
>
> --- Comment #12 from rguenth at gcc dot gnu
#24 from rguenther at suse dot de 2009-07-15 13:58 ---
> Subject: Re: [4.4/4.5 Regression] internal
> compiler error: in compute_antic, at tree-ssa-pre.c:2501
>
> On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
>
>> --- Comment #23 from dberlin at gcc dot
--- 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
--- 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 a
--- 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 gc
--- 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 AVAIL_
--- 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
--- 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 searc
--- 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 by
--- Comment #20 from dberlin at gcc dot gnu dot org 2009-02-18 02:54
---
Subject: Re: loop number of iterations analysis
not working
If the program terminates before i would wrap, then the number of
iterations was not MAXINT.
And since it can't wrap, it is not infinite in any
--- 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 i
--- 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 shoul
--- 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
--- 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
--- 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
wrote:
>
>
> --- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-0
--- 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
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
>> ---
Comment #8 from rguenther at suse dot de 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
>&
-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 const
--- 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 this
--- 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 a
--- 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 somethin
r 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 wr
--- 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
--- 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
in
--- 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, r
--- 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 t
--- 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 don
--- 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 in
--- 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, No
--- 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
--- 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;
Repla
--- 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 PROTEC
t; Subject: Re: [4.4 Regression] calculix gets
>> wrong 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
>> > ---
>
--- 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 obvio
--- 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 DTR
--- 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 comp
--- 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 d
--- 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 do
--- 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.
tree_purge_de
--- 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 do
--- 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
&l
--- 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 bet
--- 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]> wrot
--- 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:
>
>
> --
>
--- 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.
It
--- 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 (pe
--- 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 a
--- 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
--- 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 :)
--- 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:5
--- 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 ---
> Subje
--- 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 -
--- 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
--- 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
--- 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 heur
--- 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 2007
--- 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:
>
--- 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
--- 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
--- 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 chang
--- 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:
>
>
> --- Commen
--- 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 belys
--- 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
--- 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
--- 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 jak
--- 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
--- 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 cap
--- 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
--- 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
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- 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
8 from jakub at redhat 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 -0000, dberlin at dberlin dot org wrote:
> > > If you take address of the whole struct rather
--- 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
--- 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:
> >
> >
--- 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
--- 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
--- 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 sur
--- 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
--- 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 g
--- 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
recovere
--- 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 commi
--- 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]
--- 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 13
--- 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 branch
--- 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 200
--- 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
--- 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
--- 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
--- 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 fu
--- 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 rguenth
--- 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 val
--- 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
--- 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
--- 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
1 - 100 of 410 matches
Mail list logo
