https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69013
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #11 from davidxl at google dot com ---
The false negative bug introduced in the patch is fixed. Will submit the patch
for review soon.
(In reply to davidxl from comment #10)
> My patch does this.
> 1) it first does aggr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #10 from davidxl at google dot com ---
My patch does this.
1) it first does aggressive simplification iteratively (more rules can be added
later).
2) it then does normalization by building up larger predicate trees by
following ud
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #8 from davidxl at google dot com ---
Created attachment 31495
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31495&action=edit
Patch file : cleanup + more predicate simplification rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #10 from davidxl at google dot com ---
When an incoming edge to a phi is a critical edge, the 'use BB' for the phi arg
should be in the split BB of the edge. Pushing the use into either the Source
BB or the dest BB will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #9 from davidxl at google dot com ---
(In reply to Richard Biener from comment #5)
> Confirmed with the C++ FE, works with the C FE. Does not warn on trunk (for
> no good reason I think, the reason seems to be presence o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #8 from davidxl at google dot com ---
(In reply to Neil Vachharajani from comment #7)
> It seems like the whole problem is that the loop early exit goes through
> bb_6 which is the same path the back-edge goes through.
There i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378
--- Comment #3 from davidxl at google dot com ---
Can the resolver node be updated? or a new dispatcher/resolver is created?
The user code looks fine to me, which exposes the implementation limitation.
David
(In reply to Sriraman Tallam from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375
--- Comment #3 from davidxl at google dot com ---
(In reply to Sriraman Tallam from comment #2)
> IMO, This is working as expected.
>
> You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and
> mv12-aux.cc do not se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #21 from davidxl at google dot com 2012-09-11 18:08:26 UTC ---
Assuming the size of histogram for the same file does not vary that
much, is it better to round the size to the next power of 2 -- 60
entries will need print out 64 etc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #19 from davidxl at google dot com 2012-09-11 17:44:29 UTC ---
How much saving do we get by not writing out the 0 entries? With the
proposed change, how less frequent is the problem occuring?
David
On Tue, Sep 11, 2012 at 10:38 AM
--- Comment #2 from davidxl at google dot com 2008-06-06 18:00 ---
(In reply to comment #1)
> The failures disappear with the following patch:
>
> --- /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/cdce3.C2008-06-05
> 08:50:23.0 +0200
> +++ /opt/gcc/gcc-4.4-work/
15 matches
Mail list logo
