[Bug c++/59032] New: [4.8/4.9 Regression] ICE incrementing vector type

[Bug c++/59032] New: [4.8/4.9 Regression] ICE incrementing vector type

[reichelt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

            Bug ID: 59032
           Summary: [4.8/4.9 Regression] ICE incrementing vector type
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet triggers an ICE since GCC 4.8.0:

============================================
void foo()
{
  float v __attribute__((vector_size(8)));
  ++v;
}
============================================

bug.cc: In function 'void foo()':
bug.cc:4:5: error: can't convert between vector values of different size
   ++v;
     ^
bug.cc:4:6: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in fold_binary_loc, at fold-const.c:10381
   ++v;
      ^
0xd356c6 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
        ../../gcc/gcc/tree.c:9472
0x91bc32 tree_class_check
        ../../gcc/gcc/tree.h:2815
0x91bc32 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
        ../../gcc/gcc/fold-const.c:10381
0x925a2a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
        ../../gcc/gcc/fold-const.c:15048
0x90389d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
        ../../gcc/gcc/fold-const.c:10035
0x925a2a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
        ../../gcc/gcc/fold-const.c:15048
0x98dde6 gimplify_self_mod_expr(tree_node**, gimple_statement_d**,
gimple_statement_d**, bool, tree_node*)
        ../../gcc/gcc/gimplify.c:2400
0x9872aa gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:7665
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
        ../../gcc/gcc/gimplify.c:5657
0x9884cf gimplify_cleanup_point_expr
        ../../gcc/gcc/gimplify.c:5433
0x9884cf gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8088
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
        ../../gcc/gcc/gimplify.c:5657
0x987f1b gimplify_statement_list
        ../../gcc/gcc/gimplify.c:1548
0x987f1b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:8140
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
        ../../gcc/gcc/gimplify.c:5657
0x98c7e5 gimplify_bind_expr
        ../../gcc/gcc/gimplify.c:1229
0x9883ac gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
        ../../gcc/gcc/gimplify.c:7922
0x98b956 gimplify_stmt(tree_node**, gimple_statement_d**)
        ../../gcc/gcc/gimplify.c:5657
0x98d0ce gimplify_body(tree_node*, bool)
        ../../gcc/gcc/gimplify.c:8832
0x98d626 gimplify_function_tree(tree_node*)
        ../../gcc/gcc/gimplify.c:8970
Please submit a full bug report, [etc.]

Btw, the error message seems to be bogus, too. The C-frontend gives a better
diagnostic (and doesn't crash):

bug.c: In function 'foo':
bug.c:4:3: error: wrong type argument to increment
   ++v;

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[reichelt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

Volker Reichelt <reichelt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic,
                   |                            |ice-on-invalid-code
      Known to work|                            |4.1.0
      Known to fail|                            |4.8.0, 4.9.0

--- Comment #1 from Volker Reichelt <reichelt at gcc dot gnu.org> ---
The error message is broken since GCC 4.1.0.
With GCC 4.0.0 I get a decent message:

bug.cc: In function 'void foo()':
bug.cc:4: error: no pre-increment operator for type

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.3

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-10
     Ever confirmed|0                           |1

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #2 from vries at gcc dot gnu.org ---
Tentative patch:
...
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index bcb8782..8566e58 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5665,7 +5665,8 @@ cp_build_unary_op (enum tree_code code, tree xarg, int
noconvert,

       /* Report invalid types.  */

-      if (!(arg = build_expr_type_conversion (WANT_ARITH | WANT_POINTER,
+      if (!(arg = build_expr_type_conversion (WANT_INT | WANT_FLOAT
+                                             | WANT_POINTER,
                          arg, true)))
    {
      if (code == PREINCREMENT_EXPR)
...

WANT_ARITH is defined as:
...
#define WANT_ARITH      (WANT_INT | WANT_FLOAT | WANT_VECTOR_OR_COMPLEX)
...
so the patch effectively removes WANT_VECTOR_OR_COMPLEX. AFAIU the COMPLEX case
is already handled at this point, so there shouldn't be any effect for those.

This patch brings back the old error message:
...
test.c: In function ‘void foo()’:
test.c:4:5: error: no pre-increment operator for type
   ++v;
     ^
...
>From gcc-bugs-return-434140-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 10 09:16:09 2013
Return-Path: <gcc-bugs-return-434140-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28993 invoked by alias); 10 Nov 2013 09:16:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28954 invoked by uid 48); 10 Nov 2013 09:16:00 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/59008] [4.9 Regression] ICEs in try_make_edge_direct_simple_call / propagate_controlled_uses
Date: Sun, 10 Nov 2013 09:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-59008-4-Sy1NeQUf0I@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59008-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59008-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00917.txt.bz2
Content-length: 383

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY008

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-10
     Ever confirmed|0                           |1

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
I wonder if it would take more than replacing:

          inc = integer_one_node;

with something like:

          inc = VECTOR_TYPE_P (argtype)
                ? build_one_cst (argtype)
                : integer_one_node;

(or even unconditionally build_one_cst)

to support increment/decrement for vectors. We already support v=v+1, so it
wouldn't be a large extension.

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

--- Comment #4 from vries at gcc dot gnu.org ---
> We already support v=v+1, so it wouldn't be a large extension.

Hmm, indeed. If found some code in cp_builld_binary_op marked with this
comment:
...
  /* In case when one of the operands of the binary operation is
     a vector and another is a scalar -- convert scalar to vector.  */
...

I've tried to do something similar in cp_build_unary_op. Tentative patch:
...
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index bcb8782..0554664 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5746,7 +5746,38 @@ cp_build_unary_op (enum tree_code code, tree xarg, int
noconvert,
        else
          inc = integer_one_node;

-       inc = cp_convert (argtype, inc, complain);
+       /* In case when the operand of the unary operation is a vector --
+          convert scalar inc to vector.  */
+       if (TREE_CODE (TREE_TYPE (arg)) == VECTOR_TYPE)
+         {
+           enum stv_conv convert_flag;
+           enum tree_code pm_code = ((code == PREINCREMENT_EXPR
+                                      || code == POSTINCREMENT_EXPR)
+                                     ? PLUS_EXPR
+                                     : MINUS_EXPR);
+
+           convert_flag = scalar_to_vector (input_location, pm_code, arg, inc,
+                                            complain & tf_error);
+
+           switch (convert_flag)
+             {
+             case stv_error:
+               return error_mark_node;
+             case stv_firstarg:
+               gcc_unreachable ();
+             case stv_secondarg:
+               {
+                 inc = save_expr (inc);
+                 inc = convert (TREE_TYPE (TREE_TYPE (arg)), inc);
+                 inc = build_vector_from_val (TREE_TYPE (arg), inc);
+                 break;
+               }
+             default:
+               break;
+             }
+         }
+       else
+         inc = cp_convert (argtype, inc, complain);

        /* If 'arg' is an Objective-C PROPERTY_REF expression, then we
           need to ask Objective-C to build the increment or decrement
...

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to vries from comment #4)
> I've tried to do something similar in cp_build_unary_op. Tentative patch:

That seems very complicated. We know the arguments, so we know which has to be
converted to what. You could probably make cp_build_unary_op call
cp_build_binary_op and cp_build_modify_expr (expand ++v as v=v+1), but I expect
something like the 1-liner in comment #3 should be enough, no?

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |vries at gcc dot gnu.org

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 31287
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31287&action=edit
tentative patch

> but I expect something like the 1-liner in comment #3 should be enough, no?

Agree. I've added the fix also for c++.

I'll test this patch.

[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

--- Comment #7 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Nov 27 10:00:48 2013
New Revision: 205439

URL: http://gcc.gnu.org/viewcvs?rev=205439&root=gcc&view=rev
Log:
Handle vector increment/decrement in build_unary_op

2013-11-27  Tom de Vries  <tom@codesourcery.com>
        Marc Glisse  <marc.glisse@inria.fr>

    PR c++/59032
    * c-typeck.c (build_unary_op): Allow vector increment and decrement.

    * typeck.c (cp_build_unary_op): Allow vector increment and decrement.

    * c-c++-common/pr59032.c: New testcase.

Added:
    trunk/gcc/testsuite/c-c++-common/pr59032.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++/59032] [4.8 Regression] ICE incrementing vector type

[reichelt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

Volker Reichelt <reichelt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |ice-on-valid-code
            Summary|[4.8/4.9 Regression] ICE    |[4.8 Regression] ICE
                   |incrementing vector type    |incrementing vector type
      Known to fail|4.9.0                       |

--- Comment #8 from Volker Reichelt <reichelt at gcc dot gnu.org> ---
Fixed for 4.9.0.

Do you want to backport the patch to the 4.8 branch or should this PR be
closed?

[Bug c++/59032] [4.8 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Dec  2 08:37:23 2013
New Revision: 205584

URL: http://gcc.gnu.org/viewcvs?rev=205584&root=gcc&view=rev
Log:
Handle vector increment/decrement in build_unary_op

2013-11-27  Tom de Vries  <tom@codesourcery.com>
        Marc Glisse  <marc.glisse@inria.fr>

    PR c++/59032
    * c-typeck.c (build_unary_op): Allow vector increment and decrement.

    * typeck.c (cp_build_unary_op): Allow vector increment and decrement.

    * c-c++-common/pr59032.c: New testcase.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr59032.c
Modified:
    branches/gcc-4_8-branch/gcc/c/ChangeLog
    branches/gcc-4_8-branch/gcc/c/c-typeck.c
    branches/gcc-4_8-branch/gcc/cp/ChangeLog
    branches/gcc-4_8-branch/gcc/cp/typeck.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/59032] [4.8 Regression] ICE incrementing vector type

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from vries at gcc dot gnu.org ---
Fixed on trunk and 4.8 branch.