https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #34 from Jeffrey A. Law ---
*** Bug 66992 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #36 from Patrick Palka ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01439.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #37 from Domani Hannes ---
With the new patch there is still a warning with this example:
=== 8< ===
int f(void);
int test(void)
{
int baz[4];
int q = 0;
int d, i, j, sum;
for (i = 0; i < 2; i++)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #38 from Patrick Palka ---
Author: ppalka
Date: Wed Mar 30 00:55:00 2016
New Revision: 234544
URL: https://gcc.gnu.org/viewcvs?rev=234544&root=gcc&view=rev
Log:
PR tree-optimization/59124 (bogus -Warray-bounds warning)
gcc/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #39 from Patrick Palka ---
(In reply to Domani Hannes from comment #37)
> With the new patch there is still a warning with this example:
> === 8< ===
> int f(void);
>
> int test(void)
> {
> int baz[4];
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #17 from Jakub Jelinek ---
GCC 4.9.3 has been released.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.9.3 |4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #18 from b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #19 from baoshan ---
I did a little investigation to the code:
The warning occurs because tree_int_cst_lt (up_bound, up_sub) is true here:
else if (TREE_CODE (up_sub) == INTEGER_CST
&& (ignore_off_by_one
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #21 from baoshan ---
(In reply to Manuel López-Ibáñez from comment #20)
> (In reply to baoshan from comment #19)
> > We can see the value of up_sub is represented as unsigned int value
> > 4294967291 which is really weird to me, it su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #22 from Manuel López-Ibáñez ---
(In reply to baoshan from comment #21)
> Don't you think the range value is strange? how it is possible the range
> value is so big according the code?
j = i - 1 is actually j = i + 4294967295 because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #23 from baoshan ---
(In reply to Manuel López-Ibáñez from comment #22)
> (In reply to baoshan from comment #21)
> > Don't you think the range value is strange? how it is possible the range
> > value is so big according the code?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #24 from Andrew Pinski ---
(In reply to baoshan from comment #23)
> I have seen two places that would convert "A-1" to "A+(-1)", and due the
> type is unsigned int, it would be converted to "A+4294967295". This looks
> not right to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #25 from baoshan ---
(In reply to Andrew Pinski from comment #24)
> (In reply to baoshan from comment #23)
> > I have seen two places that would convert "A-1" to "A+(-1)", and due the
> > type is unsigned int, it would be converted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #26 from Jakub Jelinek ---
(In reply to baoshan from comment #25)
> > Why wrapping is well defined for unsigned types so adding 4294967295 is the
> > same as subtracting by 1.
>
> What is wrapping? and where it is defined? I don't kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #27 from baoshan ---
> It seems GCC at some moment unrolls the loop and creates such block with
> those ranges. Probably, the block is unreachable, but it would be better to
> not create it in the first place. Finding out where and wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #28 from Manuel López-Ibáñez ---
(In reply to baoshan from comment #27)
> > It seems GCC at some moment unrolls the loop and creates such block with
> > those ranges. Probably, the block is unreachable, but it would be better to
> > n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #29 from baoshan ---
> However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> times + 1). Why is this estimate wrong?
The max value of n is 6, so the max value of i is 5 as "i < n", then the max
value of j is 4 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #30 from Manuel López-Ibáñez ---
(In reply to baoshan from comment #29)
> > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> > times + 1). Why is this estimate wrong?
>
> The max value of n is 6, so the max v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #31 from baoshan ---
(In reply to Manuel López-Ibáñez from comment #30)
> (In reply to baoshan from comment #29)
> > > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> > > times + 1). Why is this estimate wron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #32 from baoshan ---
(In reply to Manuel López-Ibáñez from comment #30)
> (In reply to baoshan from comment #29)
> > > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5
> > > times + 1). Why is this estimate wron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #33 from Manuel López-Ibáñez ---
(In reply to baoshan from comment #32)
> And I think it is not wrong, it's just inaccurate, and it is not making any
> wrong result in running time.
>
> Can you point me how to proceed?
To be honest,
24 matches
Mail list logo
