--- Comment #9 from zadeck at naturalbridge dot com 2010-01-08 01:56
---
Alexandre,
i am surprised that we have gotten this far and never seen this kind of
failure.
I had actually thought that there were earlier passes that added
initialization. If that is true, then the real
--- Comment #11 from zadeck at naturalbridge dot com 2010-01-08 03:52
---
I really do not know what to say here. There is a first do no harm principal
here. it does not sound like this is really a bug and i do not think that
mucking with the compiler to make a test on a program that
--- Comment #5 from zadeck at naturalbridge dot com 2010-02-04 14:57
---
Richi, you are, of course, correct.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zadeck at naturalbridge dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45587
--- Comment #2 from zadeck at naturalbridge dot com 2010-09-07 20:31
---
Subject: Re: the processor(s) that read the .texi files
mess up.
thanks, i will fix the doc and commit.
On 09/07/2010 03:54 PM, joseph at codesourcery dot com wrote:
> --- Comment #1 from joseph
--- Comment #3 from zadeck at naturalbridge dot com 2010-09-07 20:43
---
i am fixing the doc as joseph suggests, this is not a bug with the tool.
will commit after i look at the results.
--
zadeck at naturalbridge dot com changed:
What|Removed
--- Comment #5 from zadeck at naturalbridge dot com 2010-09-08 03:42
---
Subject: Re: the processor(s) that read the .texi files
mess up.
On 09/07/2010 11:38 PM, zadeck at gcc dot gnu dot org wrote:
> --- Comment #4 from zadeck at gcc dot gnu dot org 2010-09-08 03
--- Comment #6 from zadeck at naturalbridge dot com 2010-05-19 13:41
---
I have a deadline and do not have time to play with this. The comparison
function in df-scan.c, df_ref_compare, is not stable according to what has been
discussed in pr42157. however, it does satisfy the
--- Comment #8 from zadeck at naturalbridge dot com 2010-05-19 14:06
---
df maintainers cannot approve their own patches. you should get bonzini or
any other back end maintainer to approve it.
thanks for doing the testing.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from zadeck at naturalbridge dot com 2010-06-04 17:18
---
I would just like to say that i think that target_reinit should be removed.
It is nothing but trouble. We tried to use it on our private port and it was
very slow and most of the time ended up crashing
--- Comment #4 from zadeck at naturalbridge dot com 2010-06-05 11:44
---
richard,
the reason that i went into such details about my port in (2) was to get the
reinit_regs issue out in a place so that if someone decided to take on this
beast, they had all of the issues in front of
--- Comment #16 from zadeck at naturalbridge dot com 2007-10-24 12:14
---
Subject: Re: inf loop/long compile time, time spent in var-tracking.c
rguenth at gcc dot gnu dot org wrote:
> --- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-24 12:01
> ---
> Btw,
--- Comment #6 from zadeck at naturalbridge dot com 2007-10-29 14:09
---
These stores to the stack are not really anything that dse can handle. It is
good at removing stores addressed off the frame pointer that go dead when the
function returns, but it must be more conservative with
--- Comment #7 from zadeck at naturalbridge dot com 2007-10-30 00:38
---
Subject: Re: -mstrict-align can an extra for struct agrument
passing
zadeck at naturalbridge dot com wrote:
> --- Comment #6 from zadeck at naturalbridge dot com 2007-10-29 14:09
> ---
> The
--- Comment #3 from zadeck at naturalbridge dot com 2007-11-05 22:16
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
steven at gcc dot gnu dot org wrote:
> --- Comment #2 from steven at gcc dot gnu dot org 2007-11-05 21
--- Comment #7 from zadeck at naturalbridge dot com 2007-11-06 21:21
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11
--- Comment #9 from zadeck at naturalbridge dot com 2007-11-06 21:52
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-11
--- Comment #10 from zadeck at naturalbridge dot com 2007-11-07 18:44
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
This patch keeps recursive functions from being marked as pure or const.
Full testing in progress on x86-64
--- Comment #11 from zadeck at naturalbridge dot com 2007-11-08 01:23
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
zadeck at naturalbridge dot com wrote:
> --- Comment #10 from zadeck at naturalbridge dot com 2007-11
--- Comment #15 from zadeck at naturalbridge dot com 2007-11-08 16:49
---
fixed
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
Status|NEW
--- Comment #14 from zadeck at naturalbridge dot com 2007-11-08 16:48
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
Richard Guenther wrote:
> On 11/7/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>>
--- Comment #3 from zadeck at naturalbridge dot com 2007-11-30 15:33
---
32 or 64 bit?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
--- Comment #5 from zadeck at naturalbridge dot com 2007-12-01 13:55
---
Created an attachment (id=14677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14677&action=view)
possible patch to fix this
andreas,
would you try this patch? I will try to make a small test case
--- Comment #2 from zadeck at naturalbridge dot com 2007-12-09 13:25
---
Subject: Re: [4.3 regression] gnat1 takes too long
to compile g-catiio.adb with SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #1 from steven at gcc dot gnu dot org 2007-12-09 09
--- Comment #3 from zadeck at naturalbridge dot com 2007-12-09 13:26
---
Subject: Re: [4.3 regression] gnat1 takes too long
to compile g-catiio.adb with SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #1 from steven at gcc dot gnu dot org 2007-12-09 09
--- Comment #11 from zadeck at naturalbridge dot com 2007-12-10 13:02
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #10 from steven at gcc dot gnu dot org 2007-12-10 12:32
> ---
&g
--- Comment #8 from zadeck at naturalbridge dot com 2007-12-10 18:15
---
Subject: Re: [4.3 regression] Invalid code reordering
jakub at gcc dot gnu dot org wrote:
> --- Comment #7 from jakub at gcc dot gnu dot org 2007-12-10 18:01 ---
> Created an attachment (id
--- Comment #14 from zadeck at naturalbridge dot com 2007-12-10 19:13
---
[13:51]you wont believe this
[13:51] yes
[13:51]but that SJLJ thing, that's almost entirely call
overhead
[13:52] stevenb: calling what ?
[13:52]the calls to df_
--- Comment #10 from zadeck at naturalbridge dot com 2007-12-10 20:02
---
Subject: Re: [4.3 regression] Invalid code reordering
jakub at gcc dot gnu dot org wrote:
> --- Comment #9 from jakub at gcc dot gnu dot org 2007-12-10 19:35 ---
> Created an attachment (id
--- Comment #11 from zadeck at naturalbridge dot com 2007-12-10 20:46
---
Subject: [4.3 regression] Invalid code reordering
This patch fixes where the move insn is inserted on pre increments. it
had been inserted before the auto inc but this is not correct. it needs
to replace the
--- Comment #14 from zadeck at naturalbridge dot com 2007-12-10 21:32
---
Subject: Re: [4.3 regression] Invalid code reordering
Richard Guenther wrote:
> On Dec 10, 2007 9:46 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> This patch fixes where the move insn
--- Comment #15 from zadeck at naturalbridge dot com 2007-12-10 21:33
---
committed
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
Status
--- Comment #17 from zadeck at naturalbridge dot com 2007-12-11 13:30
---
Created an attachment (id=14729)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14729&action=view)
fixup of stevens hack
This hack cuts the -O compile time for the c testcase from 35 to 2 seconds.
m
--- Comment #18 from zadeck at naturalbridge dot com 2007-12-11 13:55
---
The thing i forgot to say in the previous post was that i had to change stevens
patch because the way that it was written causes df verify errors. You cannot
make the gen set in a block dependent on the output
--- Comment #31 from zadeck at naturalbridge dot com 2007-12-11 15:23
---
why should r28 be live at the top of block 2? i do not know the pa at all, but
the only things that are live at the top of block 2, which can only be entered
by falling out of the entry. Things that are defined
--- Comment #21 from zadeck at naturalbridge dot com 2007-12-14 19:55
---
I am confused about comment #20. Are these constraint failures caused by the
proposed patch? are they independent of the patch? why is this related to the
performance issues in doing SJLJ analysis?
--
http
--- Comment #23 from zadeck at naturalbridge dot com 2007-12-14 20:07
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
joel at gcc dot gnu dot org wrote:
> --- Comment #22 from joel at gcc dot gnu dot org 2007-12-14 20:00 ---
> (In re
--- Comment #29 from zadeck at naturalbridge dot com 2007-12-16 13:56
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #28 from steven at gcc dot gnu dot org 2007-12-16 12:01
> ---
>
--- Comment #32 from zadeck at naturalbridge dot com 2007-12-17 13:21
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #31 from steven at gcc dot gnu dot org 2007-12-17 10:55
> ---
--- Comment #34 from zadeck at naturalbridge dot com 2007-12-17 16:01
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
ludovic at ludovic-brenta dot org wrote:
> --- Comment #33 from ludovic at ludovic-brenta dot org 2007-12-17 15
--- Comment #36 from zadeck at naturalbridge dot com 2007-12-17 16:33
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
ludovic at ludovic-brenta dot org wrote:
> --- Comment #35 from ludovic at ludovic-brenta dot org 2007-12-17 16
--- Comment #42 from zadeck at naturalbridge dot com 2007-12-20 01:56
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #41 from steven at gcc dot gnu dot org 2007-12-19 23:57
> ---
>
--- Comment #41 from zadeck at naturalbridge dot com 2007-12-20 03:06
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
> --- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29
> ---
> C
--- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
> --- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52
> ---
> C
--- Comment #45 from zadeck at naturalbridge dot com 2007-12-20 15:31
---
Subject: Re: Inordinate compile times on large
routines
stevenb dot gcc at gmail dot com wrote:
> --- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
> ---
> Su
--- Comment #46 from zadeck at naturalbridge dot com 2007-12-20 16:06
---
Subject: Re: Inordinate compile times on large
routines
> indexes will be 0, 1, 2, 3.
>
> there are no def-def chains, and in particular there are no artificial
> def to artificial def ch
--- Comment #48 from zadeck at naturalbridge dot com 2007-12-20 17:28
---
Created an attachment (id=14801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14801&action=view)
patch to count different types of def-use chains
this patch replaces the one munged by b
--- Comment #45 from zadeck at naturalbridge dot com 2008-01-02 23:17
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
mmitchel at gcc dot gnu dot org wrote:
> --- Comment #44 from mmitchel at gcc dot gnu dot org 2008-01-02 23
--- Comment #17 from zadeck at naturalbridge dot com 2008-01-09 20:49
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ghazi at gcc dot gnu dot org wrote:
> --- Comment #16 from ghazi at gcc dot gnu dot org 2008-01-09 18
--- Comment #48 from zadeck at naturalbridge dot com 2008-01-10 18:44
---
Subject: Re:
I do not want to commit this patch until after seongbae gets the new
node visiting sorted out.
This patch does for the rd problem what
http://gcc.gnu.org/bugzilla/attachment.cgi?id=14729
does for
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-11 13:15
---
stevens patch bootstrapped and regression tested on x86-86, ppc-32 and ia-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-11 13:09
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ghazi at gcc dot gnu dot org wrote:
> --- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-11 03
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-12 13:16
---
I know what this bug is but i do not actually know how to find it. The bug is
caused by someone abandoning a basic block without going thur the api to
properly delete it or merge it into another block.
any
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-12 16:34
---
i personally think that this patch in #8 is not the right way to go.
unless there is a compelling argument that initializing this is going to have
some negative performance effect, we should properly initialize
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-12 17:05
---
until someone has the slightest bit of evidence that initializing the
datastructure is costly, this is just a waste of time.
peter wrote the code this way to be cute, not because there was any reason to
--- Comment #5 from zadeck at naturalbridge dot com 2008-04-13 19:31
---
Subject: Re: ra-conflict does not handle subregs
optimally
hutchinsonandy at gcc dot gnu dot org wrote:
> --- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-04-13
> 19:15 ---
> Pl
--- Comment #11 from zadeck at naturalbridge dot com 2008-04-20 21:21
---
Subject: Re: [4.4 Regression] heisenbug in tree
vectorizer
rguenth at gcc dot gnu dot org wrote:
> --- Comment #10 from rguenth at gcc dot gnu dot org 2008-04-20 20:39
> ---
> What is thi
--- Comment #7 from zadeck at naturalbridge dot com 2008-04-25 21:34
---
any regressions, if any exist at all, must be addressed by vlad's new register
allocator.
--
zadeck at naturalbridge dot com changed:
What|Removed |
--- Comment #1 from zadeck at naturalbridge dot com 2008-05-08 16:46
---
Subject: Re: [4.4 Regression] g++.dg/tree-ssa/pr19637.C
ICEs with 135041 -> 135057
Here is the bug. I do not know if this is just an illegal insn
generated by a bad port or if we are missing something in
--- Comment #5 from zadeck at naturalbridge dot com 2008-05-08 23:04
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 -> 135057
steven at gcc dot gnu dot org wrote:
> --- Comment #4 from steven at gcc dot gnu dot org 2008-05-08 22:27
> ---
&
--- Comment #8 from zadeck at naturalbridge dot com 2008-05-09 11:20
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 -> 135057
hp at gcc dot gnu dot org wrote:
> --- Comment #7 from hp at gcc dot gnu dot org 2008-05-09 10:16 ---
> (In
--- Comment #10 from zadeck at naturalbridge dot com 2008-05-09 11:58
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 -> 135057
bonzini at gnu dot org wrote:
> --- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 ---
> You know I&#x
--- Comment #11 from zadeck at naturalbridge dot com 2008-05-09 12:25
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 -> 135057
zadeck at naturalbridge dot com wrote:
> --- Comment #10 from zadeck at naturalbridge dot com 2008-05-09
--- Comment #12 from zadeck at naturalbridge dot com 2008-05-09 12:29
---
Patch committed.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #5 from zadeck at naturalbridge dot com 2008-05-10 20:29
---
Subject: Re: [4.4 Regression] wrong code with -O2 -fgcse-sm
rguenth at gcc dot gnu dot org wrote:
> --- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 15:04
> ---
> Kenny, that&#x
--- Comment #6 from zadeck at naturalbridge dot com 2008-05-10 21:27
---
fixed with commit of patch.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #3 from zadeck at naturalbridge dot com 2008-05-29 13:49
---
Subject: Re: [4.3/4.4 Regression] Hang in df_analyze
bonzini at gnu dot org wrote:
> --- Comment #2 from bonzini at gnu dot org 2008-05-29 13:31 ---
> looks like a loop with 5000 basic
--- Comment #2 from zadeck at naturalbridge dot com 2008-07-01 13:53
---
Fixed as revision 137284 and 137285.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #73 from zadeck at naturalbridge dot com 2008-07-10 19:40
---
Subject: Re: Inordinate compile times on large
routines
rguenth at gcc dot gnu dot org wrote:
> --- Comment #72 from rguenth at gcc dot gnu dot org 2008-07-10 19:37
> ---
> The memory counte
--- Comment #23 from Kenneth dot Zadeck at NaturalBridge dot com
2007-10-08 12:35 ---
Subject: Re: [4.3 regression]: wrong code with -fforce-addr
Your (a) solution would only paper over the problem: dse assumes that
it can see all of the loads and stores off of the frame in more
--- Comment #2 from Kenneth dot Zadeck at NaturalBridge dot com 2008-03-10
01:48 ---
I tested the latest patch on ppc-32 and ppc-64 and there were no regressions.
i did have trouble applying the patch. The second frag of the update for the
test case did not apply.
--
Kenneth dot
201 - 271 of 271 matches
Mail list logo
