This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
- 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: Tue, 06 Dec 2016 15:54:44 +0000
- Subject: [Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
- Auto-submitted: auto-generated
- References: <bug-78684-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684
--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to amker from comment #6)
> > Ok, in this case I need to check idx_step is negative if it's signed type;
> > or idx_step has sign bit if it's unsigned type (negative step in effect).
> > tree_int_cst_sgn always returning 1 for (sizetype)-1 looks not working here?
>
> tree_int_cst_compare (idx_step, size_zero_node) < 0 would be also always
> false for unsigned types. Perhaps you can use wi::neg_p (idx_step) then,
Yes, I made this mistake which causes this ICE.
> that will return true whenever idx_step in corresponding signed type (with
> the same precision as idx_step's type) is negative.
>
> But, is it right to consider those as negative steps?
> I mean, say
> for (unsigned long long c = 0; c < 0x8000000000000005ULL; c +=
> 0x8000000000000001ULL)
> is actually positive step, not negative one.
It's safe? The loop is equal to below one, right?
for (unsigned long long c = 0; c < 0x8000000000000005ULL; c -=
0x7fffffffffffffffULL)