This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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)


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]