This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/68911] [6 Regression] wrong code at -Os and above on x86-64-linux-gnu (in 32- and 64-bit modes)


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]