--
What|Removed |Added
AssignedTo|dnovillo at redhat dot com |dnovillo at gcc dot gnu dot
||org
Status|NEW
--
What|Removed |Added
AssignedTo|dnovillo at redhat dot com |dnovillo at gcc dot gnu dot
||org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-03
14:34 ---
Aliasing is getting in the way of range propagation here. We don't realize that
args.length does not change during the loop, which means that we don't eliminate
the redundant load and fail
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-04
16:47 ---
Fixed with http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00127.html
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-04
17:00 ---
21855 has some analysis. Better use that one.
*** This bug has been marked as a duplicate of 21855 ***
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-04
17:00 ---
*** Bug 18178 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 19659 depends on bug 18178, which changed state.
Bug 18178 Summary: Missed opportunity for removing bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178
What|Old Value |New Value
--
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-05
14:19 ---
I will need someone with accesss to hppa to binary search the miscompiled file
from stage2 and send me a .i file.
Either that or give me access to an hppa machine. There is nothing in the PR
log that
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-07
19:48 ---
This seems to be an RTL bug in 4.0. None of the tree optimizers seem to be
doing anything wrong with this code. However, applying this patch to the test
case:
--- sp_test.ii 2005-06-06 12:02
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-09
14:37 ---
(In reply to comment #1)
> If side effects appear in the arguments, that also would be a problem, e.g.:
>
> printf("%d", i++);
> printf("%d", i++);
>
> should not
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-09
16:18 ---
Testing patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-15
11:34 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01261.html
--
What|Removed |Added
--
Bug 21916 depends on bug 22018, which changed state.
Bug 22018 Summary: [4.1 Regression] VRP miscompiles multiply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22018
What|Old Value |New Value
-O1
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14638
assignments
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-17
22:21 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01314.html
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|SUSPENDED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-16
20:42 ---
This is not really fixable.
Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-20
15:10 ---
Working on a fix.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-20
18:23 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01551.html
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-07
15:09 ---
BTW, the original case is no longer reproducible on mainline, but the test in
#35 still fails.
This happens when a pointer to volatile storage takes the address of a variable.
One way to fix this is by
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-08
18:47 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00451.html
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-13
20:14 ---
Confirmed. It doesn't work on mainline either. The warning machinery is
getting confused with the first V_MAY_DEF to j in the first call to 'bar()'.
It would probably not be too hard
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-18
03:52 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01071.html.
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-20
02:17 ---
Works for me. What's the problem?
$ gcc/xgcc -Bgcc -O2 -c pr19299.C --version
xgcc (GCC) 4.0.0 20050117 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; se
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-26
23:34 ---
Testing patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-27
04:58 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01969.html.
This does not completely get you the tail call you were looking for, but it does
address the address escaping problem. I would probably just
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31
15:23 ---
SPEC comparisons for i686 before/after kazu's patch to completely disable CSE.
The 20050127 compiler has CSE enabled. The 20050129 compiler has CSE disabled.
Compile times for SPECint were reduced
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31
15:26 ---
Similarly for em64t.
Build times for SPECint were reduced by 9.2%.
Build times for SPECfp were reduced by 7.5%.
Compiler bootstrap times were reduced by 4.4%.
Comparison between 20050127/spec-20050127
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-01
17:21 ---
Similar in nature to 19217 but in this case with flow sensitive aliasing. We
visit a dead PHI which takes the address of several variables, but since it's
dead, the alias analyzer never sees it.
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-01
20:38 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00097.html.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-14
15:20 ---
(In reply to comment #3)
> I'm not sure how to do anything but run a brand-new alias pass here and
> anywhere
> else we expose new global variables (e.g DOM?).
Perhaps the easiest approach
--
Bug 19865 depends on bug 19853, which changed state.
Bug 19853 Summary: [4.0 Regression] incorrect vops after exposing a new global
variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
What|Old Value |New Value
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-14
20:57 ---
Fixed: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00722.html.
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-14
21:08 ---
Thanks for the test case.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-14
22:06 ---
(In reply to comment #7)
> (In reply to comment #5)
> > The error occurs when building this with
> > gnat1 -I/gcc/ada -O2 pr19865.adb
> > (I've tested a gnat1 configured for s
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-05-04 04:01
---
jason added GENERIC and GIMPLE documentation recently. I don't see a ChangeLog
entry for it, though. That seems to be the last major piece of missing
documentation in the branch.
--
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-18 15:13
---
Testing patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17656
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-18 18:05
---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01502.html
--
What|Removed |Added
--
What|Removed |Added
CC|dnovillo at redhat dot com |
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 13:36
---
Disabling DOM seems to paper over the bug. Investigating.
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 18:04
---
This is fixed in tree-cleanup-branch. I'm bringing the patch into mainline.
Ben, is this test out of the libstdc++ testsuite? Do we test it by default with
make check? If not, would you mind addi
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 20:23
---
The tree alias analyzer depends on the type information given to it by alias.c.
In this case, the types of the pointers passed to the two routines have
conflicting alias sets, so they are given the same
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 20:28
---
dberlin's field-based SSA work should help here. Dan, want to take this one?
--
What|Removed |
--
What|Removed |Added
AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 20:34
---
Dan, ISTR you saying that the field based stuff would also help with arrays. Or
do we want to implement array-SSA? (I'd rather not, in principle).
*** This bug has been marked as a duplicate of
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 20:34
---
*** Bug 13765 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-17
21:11 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01414.html.
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-23
23:45 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01919.html
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-26
22:50 ---
(In reply to comment #6)
> Diego, if you are too busy, just let me know which you prefer and i'll
implement it.
>
I'll take a look, but in principle it seems to me that NMT.1 and NMT.2 sh
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-29
19:20 ---
(In reply to comment #5)
> But that is not sufficient. We are overflowing work_stack, when we really
> shouldn't. I'm looking into this now.
>
I was wrong. It is indeed possible for
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-29
20:15 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02593.html
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-29
23:01 ---
(In reply to comment #4)
> Adding a may_alias pass after fold all builtins makes this testcase works
> (I don't know if this is correct fix or not):
>
Unfortunately, it is. It's a bit
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-01
19:19 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00058.html
--
What|Removed |Added
--- Comment #28 from dnovillo at gcc dot gnu dot org 2006-11-09 19:15
---
(In reply to comment #26)
> I would very much like to see it compared with mem-ssa before mem-ssa
> branch is merged.
>
Notice that the two approaches do not negate each other. Dan's proposa
--- Comment #30 from dnovillo at gcc dot gnu dot org 2006-11-09 19:48
---
(In reply to comment #29)
> nevertheless, it is not obvious to me whether using mem-ssa over Daniel's
> proposal would bring any significant gains, which I would like to have
>
Of course. If you
--- Comment #2 from dnovillo at gcc dot gnu dot org 2006-12-12 13:51
---
Adding Andrew to CC list. Seems related to out-of-ssa changes.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-12-13 14:11
---
Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64 and
ppc64).
$ make check-gcc RUNTESTFLAGS=dg.exp=pr19633-1.c
[...]
Test Run By dnovillo on Wed Dec 13 09:05:53 2006
Native configuration is
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-12-13 16:50
---
(In reply to comment #4)
> Subject: Re: [4.3 Regression]
> gcc.dg/pr19633-1.c fails on the mainline
>
> On Wed, 2006-12-13 at 14:12 +0000, dnovillo at gcc dot gnu dot org
> wrote:
> &
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:32
---
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00959.html fixes the ICE in the
operand scanner.
The alias times should be back to saner values, but the memory consumption
problem is still there. Still looking into
--- Comment #7 from dnovillo at gcc dot gnu dot org 2006-12-13 17:41
---
(In reply to comment #6)
> (In reply to comment #5)
> > You completely misunderstood. It works for me on my *mainline* tree that
> > has
> > the mem-ssa patch applied.
> Then why does it
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:49
---
(In reply to comment #2)
> Looks like the mem-ssa patches cause this.
> There are no other patches in that time frame.
>
There must be. mem-ssa is @119760. If you can reproduce with @119760, then
le
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 22:37
---
(In reply to comment #9)
> (In reply to comment #8)
> > There must be. mem-ssa is @119760. If you can reproduce with @119760, then
> > let me know and I'll take a look.
>
> I can rep
--- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50
---
The memory problem is quite simple: We just have a *lot* of pointers and a
*lot* of addressable symbols. Here is a breakdown of what happens on the first
call to compute_may_aliases:
During the first call to
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 23:54
---
(In reply to comment #9)
> The memory problem is quite simple: We just have a *lot* of pointers and a
> *lot* of addressable symbols. Here is a breakdown of what happens on the
> first
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 02:50
---
(In reply to comment #11)
> I'll give the bitmaps a try for the operand scanner and see how it works.
>
OK. Hopefully that won't introduce a huge slowdown in the operand scanner.
Assig
--- Comment #11 from dnovillo at gcc dot gnu dot org 2006-12-14 19:29
---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > There must be. mem-ssa is @119760. If you can reproduce with @119760,
> > > then
> > &
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 19:50
---
Subject: Bug 30194
Author: dnovillo
Date: Thu Dec 14 19:50:11 2006
New Revision: 119867
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119867
Log:
PR 30194
* gcc.dg/pr19633-1.c:
--- Comment #1 from dnovillo at gcc dot gnu dot org 2006-12-19 13:49
---
This is not a valid bug report. You have failed to include even the bare
minimal information needed. Read http://gcc.gnu.org/bugs.html.
--
dnovillo at gcc dot gnu dot org changed:
What
301 - 377 of 377 matches
Mail list logo
