--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
02:32 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
02:27 ---
Subject: Bug 19786
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 02:27:37
Modified files:
gcc: ChangeLog tree-ssa-alias.c
g
--- Additional Comments From dnovillo at redhat dot com 2005-02-21 19:33
---
Subject: Re: [PR tree-optimization/19786] fix alias grouping lossage
Alexandre Oliva wrote:
> PR tree-optimization/19786
> * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add one
> ta
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-21
19:30 ---
Subject: [PR tree-optimization/19786] fix alias grouping lossage
The problem here was that we added type tags to other tag's may-alias
lists without adding them to the corresponding bitmaps. Later on,
when
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21
15:15 ---
This is an aliasing bug:
# VUSE ;
D.11241_367 = this_127->D.8251._M_impl._M_finish;
But if we do:
D.11300_379 = &this_127->D.8251._M_impl._M_finish;
__i_380 = D.11300_379;
# VUSE ;
SR.361_38
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-18
22:53 ---
Very odd... A rebuild after make clean was enough to trigger the problem.
Maybe I haven't rebuilt all of libstdc++-v3 lately, but it's odd because I'd
thought all of the relevant libstdc++ code was brought
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr
2005-02-18 20:48 ---
(In reply to comment #13)
> I can't duplicate this with a tree updated some time earlier today.
It has also disappeared for me on Fedora Core 3.
But I can still reproduce it on Fedora Core 1,
w
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-18
17:45 ---
I can't duplicate this with a tree updated some time earlier today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-16 20:04
---
I wonder if this has something to do with the dereference done through
int * const &.
This is the read from r->v._M_impl._M_finish in the loop.
D.16053 = &r.52D.16052->vD.11757;
{
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-16 19:14
---
I'm still looking into it.
While with -fno-strict-aliasing the important part of the dump is:
# BLOCK 20
# PRED: 33 [100.0%] (fallthru) 30 [100.0%] (fallthru)
# TMT.382D.16594_470 = PHI ;
:;
D.16463_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-16
18:59 ---
(In reply to comment #8)
> Actually, I do see problems in the tree dumps already.
> Particularly the trees look ok before LIM and are broken afterwards.
> loopinit->lim pseudo diff:
Can you look into the vo
11 matches
Mail list logo
