This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/68911] [6 Regression] wrong code at -Os and above on x86-64-linux-gnu (in 32- and 64-bit modes)
- From: "amker at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 17 Dec 2015 10:47:03 +0000
- Subject: [Bug tree-optimization/68911] [6 Regression] wrong code at -Os and above on x86-64-linux-gnu (in 32- and 64-bit modes)
- Auto-submitted: auto-generated
- References: <bug-68911-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68911
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> This goes wrong during vrp1.
> Analyzing # of iterations of loop 2
> exit condition [e_6, + , 1] <= 93
> bounds on difference of bases: -4294967202 ... 93
> result:
> zero if e_6 > 94
> # of iterations 94 - e_6, bounded by 94
> looks wrong to me, e_6 as well as the additions and comparison are performed
> in unsigned type, therefore 94 - e_6 is I believe not bounded by 94. The
> value ranges for e_6 clearly allow (and in the testcase are) some very large
> unsigned numbers, so 94 - e_6. If assuming the value of f is arbitrary (it
> is not), then the possible values of e before entering the
> while (e < 94)
> e++;
> loop are either 2, 94, 0xffffffffU or 0xfffffffeU (of course f is not
> arbitrary and as b and d are both 0, it will be actually 0xffffffffU each
> time.
> But from those 4 numbers the number of iterations would be bound by 96.
That change is supposed to handle no-wrap loop, which this is not the case
since e could be intialized with large values in unsigned type before the loop.
I will have a look in next week.