This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 21 Nov 2016 13:04:53 +0000
- Subject: [Bug middle-end/78429] [6/7 Regression] ice on valid C code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (internal compiler error: in set_value_range, at tree-vrp.c:361)
- Auto-submitted: auto-generated
- References: <bug-78429-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 21 Nov 2016, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429
>
> --- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > It's built by build_nonstandard_boolean_type via
> >
> > (gdb) bt
> > #0 0x0000000001204281 in build_nonstandard_boolean_type (precision=32)
> > at /space/rguenther/src/gcc-git/gcc/tree.c:8219
> > #1 0x000000000120e478 in build_truth_vector_type (nunits=4, vector_size=16)
> > at /space/rguenther/src/gcc-git/gcc/tree.c:10919
> > #2 0x000000000118881a in get_mask_type_for_scalar_type (
> > scalar_type=<integer_type 0x2aaaac02a690 int>)
> > at /space/rguenther/src/gcc-git/gcc/tree-vect-stmts.c:8958
> > #3 0x00000000019519b2 in search_type_for_mask_1 (
> > var=<ssa_name 0x2aaaac173438>, vinfo=0x28ab530, cache=...)
> > at /space/rguenther/src/gcc-git/gcc/tree-vect-patterns.c:3538
> > #4 0x0000000001951be3 in search_type_for_mask (var=<ssa_name
> > 0x2aaaac173438>,
> > vinfo=0x28ab530)
>
> Right, so it looks like Ada is not the only producer of non-standard boolean
> types, there is even a helper function to do it. Which means that any language
> could be affected by the regression uncovered in Ada.
In practice the above is used in vector context only (plus in the
extraction the vectorizer builds). I suppose that being more careful
at the extraction side may also help papering over this issue.
In the end having a bool_with_only_0_and_1 predicate rather than
open-coding (several variants of) the test throughout the middle-end
might be a good idea...
I don't remember off-head why we ended up with BOOLEA_TYPE element
vectors instead of using INTEGER_TYPE but I think it was because
the x86 backend actually ends up with QImode boolean vectors for
the sake of avx512 mask registers. And I opposed to treating
'char' as vector which means we now have vector<bool> with QImode
or vector<"bool"> with V4SImode for non-AVX512 targets.
So we can identify VECTOR_BOOLEAN_TYPE_P.