https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71389
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #23 from Kenneth Zadeck ---
This change to the doc looks fine to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #20 from Kenneth Zadeck ---
>> On second thoughts, for the first point, maybe a native speaker understands
>> "an available definition on any path" as "an available definition on one
>> path,
>> whatever it is", in which case the de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311
--- Comment #10 from Kenneth Zadeck ---
I have audited the patch for the non memory management issues and it is
approved.
thanks for doing this.
kenny
On 08/04/2015 07:38 AM, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311
--- Comment #5 from Kenneth Zadeck ---
thanks
> On Jul 16, 2015, at 5:12 AM, rguenth at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311
>
> Richard Biener changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32394
--- Comment #2 from Kenneth Zadeck ---
yeh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64807
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64182
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63427
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Kenneth Zadeck changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--- Comment #22 from Kenneth Zadeck ---
if i had to put money on it, i would say that it is not dead, it is only
sleeping.
kenny
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573
--- Comment #7 from Kenneth Zadeck 2012-12-07
13:39:10 UTC ---
alexandre,
when we did the dataflow stuff, my expertise was primarily in deciding which
problems could be applied to which of the passes and how and when to actually
(re)sol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53904
Bug #: 53904
Summary: trunk has valgrind errors for
c-c++-common/torture/complex-sign-mul.c on x86-64.
Classification: Unclassified
Product: gcc
Version: unknown
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53278
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
--- Comment #13 from Kenneth Zadeck
2012-05-03 13:14:31 UTC ---
The arm is one of the architectures for which lower-subreg is harmful
for some of the implementations.
kenny
On 05/03/2012 06:29 AM, Greta.Yorsh at arm dot com wrote:
> http://gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
--- Comment #7 from Kenneth Zadeck 2012-05-02
21:19:18 UTC ---
I do apologize for the lack of heads up.that was a mistake on our part.
I am also a little skeptical about the simple rtl cost model being good
enough to encompass every machine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
--- Comment #5 from Kenneth Zadeck 2012-05-02
20:35:47 UTC ---
For each mode larger than the word size of the machine, a factor is
computed. That factor is the number of times that mode is larger than
a word mode. A move is split if the cost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
Kenneth Zadeck changed:
What|Removed |Added
CC||zadeck at naturalbridge dot
--- 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 #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 #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
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 #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 #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 #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 #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 #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
--- 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 #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 #4 from zadeck at naturalbridge dot com 2009-10-03 23:57
---
Richard,
the problem is that at least for the linux world there are two elf
implementations that while they claim to be compatible are distinctly different
on the inside. LTO, for better or worse, needs to use
: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zadeck at naturalbridge dot com
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39097
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zadeck at naturalbridge dot com
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39096
--- Comment #8 from zadeck at naturalbridge dot com 2009-01-29 14:42
---
patch committed.
closed for 4.4.
richi said not to backport to 4.3 on irc.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #7 from zadeck at naturalbridge dot com 2009-01-29 14:38
---
Subject: Re: [4.3/4.4 Regression] life passes dump
option still documented
Richard Guenther wrote:
> On Wed, Jan 28, 2009 at 5:03 PM, Kenneth Zadeck
> wrote:
>
>> rguenth at gcc dot gn
--- Comment #4 from zadeck at naturalbridge dot com 2009-01-28 16:03
---
Subject: Re: [4.3/4.4 Regression] life passes dump
option still documented
rguenth at gcc dot gnu dot org wrote:
> --- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-24 10:20
> ---
>
--- Comment #17 from zadeck at naturalbridge dot com 2009-01-24 20:28
---
Subject: Re: [4.3 Regression] Hang in df_analyze
rguenth at gcc dot gnu dot org wrote:
> --- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-24 10:20
> ---
> GCC 4.3.3 is being
--- Comment #3 from zadeck at naturalbridge dot com 2009-01-10 01:57
---
Created an attachment (id=17068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17068&action=view)
patch to cause df to verify after every patch
this is a combine bug. The df verification fail
--- Comment #2 from zadeck at naturalbridge dot com 2009-01-09 12:41
---
i will have my best people work on it.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #17 from zadeck at naturalbridge dot com 2009-01-03 01:05
---
patch committed to fix this.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
dot org
ReportedBy: zadeck at naturalbridge dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38711
--- Comment #16 from zadeck at naturalbridge dot com 2009-01-03 00:35
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Kenneth Zadeck wrote:
> Steven Bosscher wrote:
>
>> On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini wrote:
>>
--- Comment #14 from zadeck at naturalbridge dot com 2009-01-02 18:54
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Steven Bosscher wrote:
> On Fri, Jan 2, 2009 at 7:37 PM, Paolo Bonzini wrote:
>
>>>> At this point, if your p
--- Comment #11 from zadeck at naturalbridge dot com 2009-01-02 18:21
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
>> I will test this patch, but we still need to resolve your issues with my
>> approach.
>>
--- Comment #9 from zadeck at naturalbridge dot com 2009-01-02 15:34
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
On looking at the code, there is an issue with the first patch. I
should have been clearing solutions_dirty flag at the start of the
--- Comment #8 from zadeck at naturalbridge dot com 2009-01-02 15:20
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
>> I think so. The global changed flag allows it to delete the case:
>>
>> loop:
>> .
--- Comment #6 from zadeck at naturalbridge dot com 2009-01-02 14:09
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
Paolo Bonzini wrote:
> Kenneth Zadeck wrote:
>
>> 2009-01-01 Kenneth Zadeck
>>
>> PR rtl-optimi
--- Comment #4 from zadeck at naturalbridge dot com 2009-01-02 00:38
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
2009-01-01 Kenneth Zadeck
PR rtl-optimization/35805
* df-problems.c (df_lr_finalize): Add recursive call to resolve lr
--- Comment #3 from zadeck at naturalbridge dot com 2008-12-29 23:40
---
additional info.
gcc.c-torture/compile/930523-1.c
on x86-32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805
--- Comment #20 from zadeck at naturalbridge dot com 2008-12-18 14:23
---
committed patch to fix this.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #16 from zadeck at naturalbridge dot com 2008-12-16 18:43
---
and how would you ask that question in a machine independent way?
I am going to find the shift sequence and if it has a set or clobber of any
currently live hard reg, i will reject the sequence.
I am working on
--- Comment #9 from zadeck at naturalbridge dot com 2008-12-15 15:32
---
Andrew,
What is your point here?
1) Is it your claim that anything that is arg_pointer_rtx related would
automatically qualify as being safe enough to remove dead stores to?
or
2) Is it your claim that if we
nt: rtl-optimization
AssignedTo: vmakarov at gcc dot gnu dot org
ReportedBy: zadeck at naturalbridge dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38532
--- Comment #13 from zadeck at naturalbridge dot com 2008-12-06 22:33
---
Subject: Re: [4.3/4.4 Regression] Hang in df_analyze
steven at gcc dot gnu dot org wrote:
> --- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25
> ---
> Patch here:
> http:/
--- Comment #20 from zadeck at naturalbridge dot com 2008-10-24 18:44
---
Subject: Re: [4.4 Regression] Revision 139827 causes Divide_X
jakub at gcc dot gnu dot org wrote:
> --- Comment #19 from jakub at gcc dot gnu dot org 2008-10-24 18:09
> ---
> This hunk in
--- Comment #12 from zadeck at naturalbridge dot com 2008-10-12 21:22
---
fixed with the above patch.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #11 from zadeck at naturalbridge dot com 2008-10-12 21:19
---
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86
Richard Guenther wrote:
> On Sun, Oct 12, 2008 at 11:12 PM, Kenneth Zadeck
> <[EMAIL PROTECTED]> wrote:
>
>> andreast a
--- Comment #8 from zadeck at naturalbridge dot com 2008-10-12 21:13
---
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86
andreast at gcc dot gnu dot org wrote:
> --- Comment #7 from andreast at gcc dot gnu dot org 2008-10-12 20:31
> ---
> I see a f
--- Comment #3 from zadeck at naturalbridge dot com 2008-10-12 04:56
---
Created an attachment (id=16485)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16485&action=view)
possible patch to fix the problem
I am pretty sure that this fixes it, but i need to do more testing.
--- Comment #23 from zadeck at naturalbridge dot com 2008-09-27 12:44
---
I do not believe honza.
My measurements at -O0 on x86-42 are about 15 refs per insn.
This is based on the following stats. (These can be reproduced using a patch
that i am about to submit).
;;total ref
--- 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 #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 #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 #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 #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
--- 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 #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 #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
--- 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 #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 #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 #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 #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 #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 #8 from zadeck at naturalbridge dot com 2008-03-20 13:59
---
Subject: Re: heisenbug in tree vectorizer
bonzini at gnu dot org wrote:
> --- Comment #7 from bonzini at gnu dot org 2008-03-20 13:51 ---
> Indeed my patch exposes additional vectorization abi
--- Comment #3 from zadeck at naturalbridge dot com 2008-03-19 19:26
---
I forgot to mention that valgrind does not find anything.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
Summary: heisenbug in tree vectorizer
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- 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
--- Comment #5 from zadeck at naturalbridge dot com 2008-02-12 14:56
---
Richi,
I looked at this code once but I really do not know this code at all and really
do not want to learn it. It will take a fair amount of time to try to figure
out what the underlying dataflow problem is and
--- Comment #3 from zadeck at naturalbridge dot com 2008-02-06 16:26
---
The dataflow changes caused, at least, the latest level of messing this up by
splitting, combining and removing a large number of passes without regard to
this antiquated system of naming the passes.
if the
--- Comment #6 from zadeck at naturalbridge dot com 2008-01-23 23:22
---
Subject: Re: [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c
execution, -O3 -fomit-frame-pointer -funroll-loops
danglin at gcc dot gnu dot org wrote:
> --- Comment #5 from danglin at gcc dot
--- Comment #3 from zadeck at naturalbridge dot com 2008-01-22 22:15
---
Subject: Re: [4.3 Regression] FAIL: gcc.c-torture/execute/va-arg-15.c
execution, -O3 -fomit-frame-pointer -funroll-loops
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #2 from dave at hiau
--- Comment #31 from zadeck at naturalbridge dot com 2008-01-22 14:35
---
resolved with the patch referenced in comment 30.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #30 from zadeck at naturalbridge dot com 2008-01-22 13:58
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
Kenneth Zadeck wrote:
> zadeck at naturalbridge dot com wrote:
>
>> --- Comment #27 from zadeck at naturalbridge dot com 2
--- Comment #28 from zadeck at naturalbridge dot com 2008-01-22 13:35
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
zadeck at naturalbridge dot com wrote:
> --- Comment #27 from zadeck at naturalbridge dot com 2008-01-21 15:36
> ---
> Su
--- Comment #27 from zadeck at naturalbridge dot com 2008-01-21 15:36
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
bonzini at gnu dot org wrote:
> --- Comment #26 from bonzini at gnu dot org 2008-01-21 14:54 ---
> Subject: Re: [4.3 Regr
--- Comment #21 from zadeck at naturalbridge dot com 2008-01-21 13:25
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
bonzini at gnu dot org wrote:
> --- Comment #20 from bonzini at gnu dot org 2008-01-21 13:21 ---
> Subject: Re: [4.3 Regr
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-21 13:02
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
bonzini at gnu dot org wrote:
> --- Comment #18 from bonzini at gnu dot org 2008-01-21 08:04 ---
> I agree with Steven. The tr
--- Comment #17 from zadeck at naturalbridge dot com 2008-01-20 23:27
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
steven at gcc dot gnu dot org wrote:
> --- Comment #16 from steven at gcc dot gnu dot org 2008-01-20 23:22
> ---
> I favo
--- Comment #15 from zadeck at naturalbridge dot com 2008-01-20 23:15
---
There appears to be an design inconsistency in the way that we have specified
the various dataflow problems with respect to the eq notes.
I hate eq notes.
In the rd patch that just went in where we trim the
--- Comment #14 from zadeck at naturalbridge dot com 2008-01-20 18:30
---
confirmed on my machine,
i will have my best people work on it.
kenny
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-20 16:34
---
Subject: Re: [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c
doesn't work
olga at gcc dot gnu dot org wrote:
> --- Comment #10 from olga at gcc dot gnu dot org 2008-01-20 16:28 -
--- Comment #12 from zadeck at naturalbridge dot com 2008-01-20 15:52
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
> --- Comment #11 from dominiq at lps dot ens dot fr 2008-01-20 15:47
> ---
> I hav
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-20 15:39
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
> --- Comment #9 from dominiq at lps dot ens dot fr 2008-01-20 15:30
> ---
>
&
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-20 15:29
---
olga,
even if the test case does not normally ice on your system, you be able to see
the bug if you run the test with valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
--- Comment #8 from zadeck at naturalbridge dot com 2008-01-20 15:24
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
> --- Comment #7 from dominiq at lps dot ens dot fr 2008-01-20 14:39
> ---
>
>>
--- Comment #6 from zadeck at naturalbridge dot com 2008-01-20 13:53
---
I need a more info to reproduce this bug. I bootstrapped and regression tested
on x86_64-unknown-linux-gnu with suse 10.3 and using
--enable-languages=c,c++,fortran --disable-multilib before committing the
patch
--- Comment #58 from zadeck at naturalbridge dot com 2008-01-20 02:13
---
The three patches that have been committed seem to have brought this under
control.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #2 from zadeck at naturalbridge dot com 2008-01-20 01:43
---
actually the commit for 34400 does not seem to effect this bug.
but the bug does have that nice heisenbug quality to it.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34874
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-19 20:13
---
I am about to commit the last fix to p34400 and at least on my machine, this
patch will make this failure disappear from the test suite. however the bug is
still there if you look with valgrind.
pinskia, i am
1 - 100 of 271 matches
Mail list logo