[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from amker at gcc dot gnu.org --- (In reply to Marek Polacek from comment #10) > So fixed? Yes, I think so.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #10 from Marek Polacek --- So fixed?
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 --- Comment #9 from amker at gcc dot gnu.org --- Author: amker Date: Thu Dec 8 10:56:41 2016 New Revision: 243431 URL: https://gcc.gnu.org/viewcvs?rev=243431=gcc=rev Log: PR middle-end/78684 * tree-vect-loop-manip.c (create_intersect_range_checks_index): Check sign bit for index step of data reference. gcc/testsuite PR middle-end/78684 * g++.dg/torture/pr78684.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr78684.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
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 < 0x8005ULL; c += > 0x8001ULL) > 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 < 0x8005ULL; c -= 0x7fffULL)
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 --- Comment #7 from Jakub Jelinek --- (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, 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 < 0x8005ULL; c += 0x8001ULL) is actually positive step, not negative one.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 --- Comment #6 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > (In reply to amker from comment #4) > > (In reply to Jakub Jelinek from comment #3) > > > neg_step is true, because DR_STEP (dr_a.dr) is (ssizetype) -8. > > > But idx_step is 0xUL. > > > Note > > > tree_int_cst_compare (idx_step, size_zero_node) < 0 > > > is just weird, why don't you use tree_int_cst_sgn? > > > > Hi Jakub, do you mean tree_int_cst_sign_bit? Thanks. > > No, I mean what I wrote, i.e. > /* Return an indication of the sign of the integer constant T. >The return value is -1 if T < 0, 0 if T == 0, and 1 if T > 0. >Note that -1 will never be returned if T's type is unsigned. */ > > int > tree_int_cst_sgn (const_tree t) > ... > defined in tree.c. 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? Thanks.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 --- Comment #5 from Jakub Jelinek --- (In reply to amker from comment #4) > (In reply to Jakub Jelinek from comment #3) > > neg_step is true, because DR_STEP (dr_a.dr) is (ssizetype) -8. > > But idx_step is 0xUL. > > Note > > tree_int_cst_compare (idx_step, size_zero_node) < 0 > > is just weird, why don't you use tree_int_cst_sgn? > > Hi Jakub, do you mean tree_int_cst_sign_bit? Thanks. No, I mean what I wrote, i.e. /* Return an indication of the sign of the integer constant T. The return value is -1 if T < 0, 0 if T == 0, and 1 if T > 0. Note that -1 will never be returned if T's type is unsigned. */ int tree_int_cst_sgn (const_tree t) ... defined in tree.c.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 --- Comment #4 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > neg_step is true, because DR_STEP (dr_a.dr) is (ssizetype) -8. > But idx_step is 0xUL. > Note > tree_int_cst_compare (idx_step, size_zero_node) < 0 > is just weird, why don't you use tree_int_cst_sgn? Hi Jakub, do you mean tree_int_cst_sign_bit? Thanks.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- neg_step is true, because DR_STEP (dr_a.dr) is (ssizetype) -8. But idx_step is 0xUL. Note tree_int_cst_compare (idx_step, size_zero_node) < 0 is just weird, why don't you use tree_int_cst_sgn?
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r240412.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684
--- Comment #1 from Matthias Klose ---
a test case without a processor specific option.
$ cat RapMapSAIndex.ii
class a {
public:
a(long);
void operator<<=(long) {
long b;
for (unsigned long c; c; c--)
d[c + b] = d[c];
}
a ();
long d[28];
};
long e;
int f;
void j() {
a h(e), i = h;
i.g() <<= f;
}
$ g++ -c -std=c++11 -Ofast RapMapSAIndex.ii
RapMapSAIndex.ii: In function 'void j()':
RapMapSAIndex.ii:14:6: internal compiler error: in
create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
void j() {
^
0xcdb7be create_intersect_range_checks_index
../../src/gcc/tree-vect-loop-manip.c:2073
0xcdb7be create_intersect_range_checks
../../src/gcc/tree-vect-loop-manip.c:2131
0xcdb7be vect_create_cond_for_alias_checks(_loop_vec_info*, tree_node**)
../../src/gcc/tree-vect-loop-manip.c:2219
0xcdbf7c vect_loop_versioning(_loop_vec_info*, unsigned int, bool)
../../src/gcc/tree-vect-loop-manip.c:2293
0xccc064 vect_transform_loop(_loop_vec_info*)
../../src/gcc/tree-vect-loop.c:6773
0xce8d62 vectorize_loops()
../../src/gcc/tree-vectorizer.c:621
Please submit a full bug report,
with preprocessed source if appropriate.
