http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
--- Comment #7 from Zdenek Dvorak ---
(In reply to Richard Biener from comment #4)
> We then fall to
>
> if (multiple_of_p (TREE_TYPE (c), c, s))
> {
> /* If C is an exact multiple of S, then its value will be reached
> before
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
--- Comment #6 from Zdenek Dvorak ---
I will have a look.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875
--- Comment #5 from Zdenek Dvorak 2013-01-07
14:11:29 UTC ---
(In reply to comment #4)
> the check of scev_probably_wraps_p below should return false
this should be "should return true"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #15 from Zdenek Dvorak 2012-12-11
18:19:40 UTC ---
Created attachment 28928
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28928
A proposed patch
This patch fixes the error (and also makes the code more clearly match wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #14 from Zdenek Dvorak 2012-12-10
18:19:07 UTC ---
This is a problem in rewrite_use_nonlinear_expr, which should leave the
statement defining the biv untouched (as suggested in the comment at its
beginning) but does not. Inves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #17 from Zdenek Dvorak 2012-01-17
11:01:45 UTC ---
> > LSM will move inter[1] to a temporary variable regardless of the locks,
> > which
> > will cause race conditions with other threads (and whether loop header is
> > copied or not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #14 from Zdenek Dvorak 2012-01-17
10:19:01 UTC ---
> > Also, the warning is at least morally right. If R <= 1, the original code
> > will
> > pass inter to foo uninitialized, which probably is not intended. So, the
> > right
> > t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #12 from Zdenek Dvorak 2012-01-16
16:25:05 UTC ---
(In reply to comment #11)
> Re-confirmed on trunk with the testcase in comment #4 and -Os:
>
> > ./cc1 -quiet t.c -Os -Wall -fdump-tree-all
> t.c: In function 'f2':
> t.c:4:11: warni
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #9 from Zdenek Dvorak 2011-05-07
19:43:21 UTC ---
Author: rakdver
Date: Sat May 7 19:43:18 2011
New Revision: 173534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173534
Log:
PR tree-optimization/48837
* tree-tailcal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #8 from Zdenek Dvorak 2011-05-04
08:33:51 UTC ---
Created attachment 24177
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24177
Fix for the issue
Indeed, once the accumulator transformation is performed, the other tail calls
in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #6 from Zdenek Dvorak 2011-04-21
11:49:36 UTC ---
I think we rely on the assumption that pointer arithmetics satisfies the
restrictions of C standard (i.e., that the pointer is within a single memory
object) on more places than just t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000
--- Comment #4 from Zdenek Dvorak 2011-03-06
10:43:41 UTC ---
Created attachment 23559
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23559
A proposed patch
This fixes the problem uncovered by the previous fix. In fix_bb_placements, we
res
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899
--- Comment #6 from Zdenek Dvorak 2011-03-04
22:41:48 UTC ---
(In reply to comment #5)
> Thanks, this patch seems to work (I've bootstrapped/regtested it on
> x86_64-linux and i686-linux together with the #c3 testcase with
> /* PR rtl-optimizatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899
--- Comment #4 from Zdenek Dvorak 2011-03-01
22:13:15 UTC ---
Created attachment 23508
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23508
proposed fix
When the non-exit path is removed during the complete peeling of the loop, we
may need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47575
--- Comment #2 from Zdenek Dvorak 2011-02-01
16:56:57 UTC ---
There is nothing in C standard requiring us to preserve global stores that are
unused, unless they are volatile. Store motion is by far not the only
optimization in gcc that affects g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
--- Comment #16 from Zdenek Dvorak 2011-02-01
11:27:13 UTC ---
(In reply to comment #15)
> Ah, the reason why pr19210-* fail is that those loops have non-const/pure call
> in it. So, while single_exit (loop) == exit, loop_only_exit_p (loop, exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
--- Comment #13 from Zdenek Dvorak 2011-01-30
18:20:21 UTC ---
(In reply to comment #10)
> I think the 2nd patch is more "sound" (that is, it's easier to see what
> effects it will have). Zdenek, do you agree?
yes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838
--- Comment #9 from Zdenek Dvorak 2011-01-17
11:04:22 UTC ---
> UGH. Everything involving ivtmp.12 is a waste of time. We really just need
> to
> realize that D1976_16 is D1971_10 + 4 which avoids all the nonsense with
> ivtmp.12 and I *think*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46675
--- Comment #29 from Zdenek Dvorak 2010-11-29
09:16:56 UTC ---
Created attachment 22561
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22561
patch to fix overflow in # of iterations analysi
Fixes overflow in # of iterations analysis -- when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46675
Zdenek Dvorak changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #28 from Zdenek Dvor
20 matches
Mail list logo
