[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|5.5 |6.0 --- Comment #10 from Jakub Jelinek --- GCC 5 branch has been closed, should be fixed in GCC 6 and later.
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 --- Comment #9 from Tom de Vries --- (In reply to Tom de Vries from comment #8) > (In reply to Tom de Vries from comment #7) > > (In reply to Tom de Vries from comment #6) > > > Hmm, at r225942 I read: > > > > Patch applies cleanly to 5 branch and fixes ICEs for original and minimal > > test-cases. > > Doing an x86_64 bootstrap and reg-test on top of 5 branch. That went ok. Started backport discussion at https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01924.html .
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 --- Comment #8 from Tom de Vries --- (In reply to Tom de Vries from comment #7) > (In reply to Tom de Vries from comment #6) > > Hmm, at r225942 I read: > > Patch applies cleanly to 5 branch and fixes ICEs for original and minimal > test-cases. Doing an x86_64 bootstrap and reg-test on top of 5 branch.
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 --- Comment #7 from Tom de Vries --- (In reply to Tom de Vries from comment #6) > Hmm, at r225942 I read: Patch applies cleanly to 5 branch and fixes ICEs for original and minimal test-cases.
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 --- Comment #6 from Tom de Vries --- Hmm, at r225942 I read: ... [graphite] fix pr61929 This fixes bootstrap of GCC with BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-nest-optimize -floop-block -floop-interchange -floop-strip-mine". It passes regstrap on amd64-linux. A previous change (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=213816), replaced isl_int with isl_val because isl_int would be deprecated. Since isl_val has stricter checks, it exposed the bug. In the test case (isl_set_max_val) would return infinity which would remain unchecked. We now check if the value returned is an integer or not, and bail out if it isn't. ... This seems to be a duplicate of PR61929.[ If we mark this as a duplicate, we should re-open PR61929 and mark it as 5 regression. ]
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 Tom de Vries changed: What|Removed |Added Target Milestone|--- |5.5
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506 --- Comment #5 from Tom de Vries --- (In reply to Martin Liška from comment #2) > Current trunk, as well as GCC 6.1.1 works fine. This is a problem in loop-interchange.c, which was removed in the 6 release (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01651.html).
[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506
--- Comment #4 from Tom de Vries ---
At the first call to build_linearized_memory_access, at the 3rd loop iteration
we have:
...
(gdb)
133 subsize = isl_set_max_val (pdr->extent, aff);
(gdb) call (char *)
isl_printer_get_str(isl_printer_print_set(isl_printer_to_str(ctx),
pdr->extent))
$5 = 0x30f6b90 "{ [1, i1, i2, i3, i4] : i4 >= 0 and i1 >= 0 and i2 >= 0 and i3
>= 0 and i4 <= 1 and i3 <= 1 }"
(gdb) call (char *)
isl_printer_get_str(isl_printer_print_aff(isl_printer_to_str(ctx), aff))
$6 = 0x30f5e30 "{ [i0, i1, i2, i3, i4] -> [(i2)] }"
(gdb) n
134 isl_aff_free (aff);
(gdb) call (char *)
isl_printer_get_str(isl_printer_print_val(isl_printer_to_str(ctx), subsize))
$7 = 0x30f8f00 "infty"
...
The infinity in subsize is propagated to size, and then 'res =
isl_constraint_set_coefficient_val (res, isl_dim_out, offset + i, size)' ICEs
because isl_constraint_set_coefficient_val expects the last argument to be an
int.
In 5.0, subsize is an isl_val:
...
isl_val *subsize;
...
subsize = isl_set_max_val (pdr->extent, aff);
...
But in 4.9, subsize is an isl_int:
...
isl_int subsize;
...
isl_set_max (pdr->extent, aff, &subsize);
...
And at the same point in execution, subsize is 1 instead of infty (which seems
to be caused by subsize being 1 before the call, and isl_set_max not having an
effect, which sound fishy).
