[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #15 from Marek Polacek --- Author: mpolacek Date: Wed Jan 27 19:13:42 2016 New Revision: 232894 URL: https://gcc.gnu.org/viewcvs?rev=232894=gcc=rev Log: PR c/68062 * c-typeck.c (build_binary_op) [EQ_EXPR, GE_EXPR]: Promote operand to unsigned, if needed. Add -Wsign-compare warning. * typeck.c (cp_build_binary_op): Promote operand to unsigned, if needed. Add -Wsign-compare warning. * c-c++-common/vector-compare-4.c: New test. Added: trunk/gcc/testsuite/c-c++-common/vector-compare-4.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #14 from Marek Polacek --- Looking into this again.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
--- Comment #12 from Richard Biener ---
(In reply to Andrew Pinski from comment #11)
> We still get the bogus IR but we don't ICE any more:
> v4qi c;
> uv4qi d;
>
> c = {a, a, a, a};
> d = {a, a, a, a};
> D.2757 = c != d;
> D.2758 = VEC_COND_EXPR ;
> D.2759 = VIEW_CONVERT_EXPR(D.2758);
>
> Also VEC_COND_EXPR really should not be there.
What's bogus with the IR? The VIEW_CONVERT need not be there as it can
be combined with the VEC_COND_EXPR RHSs. We can't drop the VEC_COND_EXPR
as c != d results in a vector bool while we want a v4qi.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #13 from Marek Polacek --- I still see the ICE.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2015-10-23 00:00:00 |2015-12-28
--- Comment #11 from Andrew Pinski ---
We still get the bogus IR but we don't ICE any more:
v4qi c;
uv4qi d;
c = {a, a, a, a};
d = {a, a, a, a};
D.2757 = c != d;
D.2758 = VEC_COND_EXPR ;
D.2759 = VIEW_CONVERT_EXPR(D.2758);
Also VEC_COND_EXPR really should not be there.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #10 from Richard Biener --- IMHO doing signed -> unsigned promotion (and consistently also for the result then) should be allowed.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 Richard Biener changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #7 from Richard Biener --- I think there was some inconsistencies in C vs. C++ FEs in this area (but as usual I don't remember exactly but I remember Uli complaining about it again at the Caulrdon). I believe it was sort-of automatic integer promotion rules should apply if they don't change vector sizes (thus, the sign promotion parts should apply). That's not "ignoring" signs but doing the appropriate (view-)conversions.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #9 from rguenther at suse dot de --- On Thu, 12 Nov 2015, uweigand at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 > > --- Comment #8 from Ulrich Weigand --- > (In reply to Richard Biener from comment #7) > > I think there was some inconsistencies in C vs. C++ FEs in this area (but as > > usual I don't remember exactly but I remember Uli complaining about it again > > at the Caulrdon). > > > > I believe it was sort-of automatic integer promotion rules should apply if > > they don't change vector sizes (thus, the sign promotion parts should > > apply). > > > > That's not "ignoring" signs but doing the appropriate (view-)conversions. > > Actually, the C vs. C++ FE inconsistency was about binary operators (+, -, > ...), not comparisons. > > For both binary and relational operators, the various applicable standards > (AltiVec + extensions, System z vector extensions, OpenCL) all agree that if > the two operands differ in signedness, the operation is not valid and should > result in an error. However, GCC has never done this, but has always accepted > these combinations (both C and C++). (At some point, we might want to change > this, but then we have to care that we don't break "vector bool" handling for > those platforms that support it.) > > The difference between C and C++ comes in when determining what to use as the > *result type* of a binary operator whose operands differ in signedness. This > does not apply to comparisons since those have a result type different from > the > input types in any case. Thanks for the clarification.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #8 from Ulrich Weigand --- (In reply to Richard Biener from comment #7) > I think there was some inconsistencies in C vs. C++ FEs in this area (but as > usual I don't remember exactly but I remember Uli complaining about it again > at the Caulrdon). > > I believe it was sort-of automatic integer promotion rules should apply if > they don't change vector sizes (thus, the sign promotion parts should apply). > > That's not "ignoring" signs but doing the appropriate (view-)conversions. Actually, the C vs. C++ FE inconsistency was about binary operators (+, -, ...), not comparisons. For both binary and relational operators, the various applicable standards (AltiVec + extensions, System z vector extensions, OpenCL) all agree that if the two operands differ in signedness, the operation is not valid and should result in an error. However, GCC has never done this, but has always accepted these combinations (both C and C++). (At some point, we might want to change this, but then we have to care that we don't break "vector bool" handling for those platforms that support it.) The difference between C and C++ comes in when determining what to use as the *result type* of a binary operator whose operands differ in signedness. This does not apply to comparisons since those have a result type different from the input types in any case.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #6 from Marek Polacek --- If we should pay attention to the sign, then maybe --- gcc/c-family/c-common.c +++ gcc/c-family/c-common.c @@ -11903,9 +11903,9 @@ vector_types_compatible_elements_p (tree t1, tree t2) && (c2 == INTEGER_TYPE || c2 == REAL_TYPE || c2 == FIXED_POINT_TYPE)); - t1 = c_common_signed_type (t1); - t2 = c_common_signed_type (t2); - /* Equality works here because c_common_signed_type uses + t1 = c_common_signed_or_unsigned_type (TYPE_UNSIGNED (t1), t1); + t2 = c_common_signed_or_unsigned_type (TYPE_UNSIGNED (t2), t2); + /* Equality works here because c_common_signed_or_unsigned_type uses TYPE_MAIN_VARIANT. */ if (t1 == t2) return true; (it has a small fallout)
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- The FEs stopped rejecting the testcase with r202364.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
--- Comment #4 from Ilya Enkovich ---
(In reply to Ilya Enkovich from comment #3)
> (In reply to Richard Biener from comment #1)
> > I suppose that is Iljas fault (only happens on trunk).
>
> Yes, -funsigned-char seems to be my fault. I'll have look.
It appears to be introduced by r229173. We now try to lower vector comparison
using optab which doesn't actually exist. This patch fixes it:
diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index 2005383..9c59402 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -1533,7 +1533,8 @@ expand_vector_operations_1 (gimple_stmt_iterator *gsi)
&& TYPE_MODE (TREE_TYPE (type)) == TYPE_MODE (TREE_TYPE (srhs1)))
{
op = optab_for_tree_code (code, TREE_TYPE (type), optab_scalar);
- if (optab_handler (op, TYPE_MODE (TREE_TYPE (type))) !=
CODE_FOR_nothing)
+ if (op != unknown_optab
+ && optab_handler (op, TYPE_MODE (TREE_TYPE (type))) !=
CODE_FOR_nothing)
{
tree slhs = make_ssa_name (TREE_TYPE (srhs1));
gimple *repl = gimple_build_assign (slhs, code, srhs1, srhs2);
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #3 from Ilya Enkovich --- (In reply to Richard Biener from comment #1) > I suppose that is Iljas fault (only happens on trunk). Yes, -funsigned-char seems to be my fault. I'll have look.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4 Summary|ICE when comparing vectors |[4.9/5/6 Regression] ICE ||when comparing vectors
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #2 from Richard Biener --- The FEs are missing a VIEW_CONVERT_EXPR around one of the operands. But I suppose 4.8 is correct in rejecting this compare with mismatched sign (though the rejection isn't dependent on the sign of char).
