[Bug c++/58845] New: Operator || and && broken for vectors

[Bug c++/58845] New: Operator || and && broken for vectors

[reichelt at gcc dot gnu.org]

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

            Bug ID: 58845
           Summary: Operator || and && broken for vectors
           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 (IMHO valid) code snippet triggers an ICE since GCC 4.8.0 when
compiled with "-O":

==========================================
void foo()
{
  int v __attribute__((vector_size(8)));
  v = v || v;
}
==========================================

bug.cc: In function 'void foo()':
bug.cc:4:12: internal compiler error: in build_int_cst_wide, at tree.c:1258
   v = v || v;
            ^
0xd213b3 build_int_cst_wide(tree_node*, unsigned long, long)
        ../../gcc/gcc/tree.c:1258
0xd216f0 double_int_to_tree(tree_node*, double_int)
        ../../gcc/gcc/tree.c:1112
0xd2173a build_int_cst(tree_node*, long)
        ../../gcc/gcc/tree.c:1089
0x9348c3 make_range(tree_node*, int*, tree_node**, tree_node**, bool*)
        ../../gcc/gcc/fold-const.c:4217
0x939952 fold_range_test
        ../../gcc/gcc/fold-const.c:4980
0x939952 fold_truth_andor
        ../../gcc/gcc/fold-const.c:8619
0x8fd0d8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
        ../../gcc/gcc/fold-const.c:12769
0x93f57c fold(tree_node*)
        ../../gcc/gcc/fold-const.c:14648
0x68901a cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
        ../../gcc/gcc/cp/typeck.c:4920
0x556b5c build_new_op_1
        ../../gcc/gcc/cp/call.c:5468
0x5576a7 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
        ../../gcc/gcc/cp/call.c:5513
0x677762 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
        ../../gcc/gcc/cp/typeck.c:3752
0x651545 cp_parser_binary_expression
        ../../gcc/gcc/cp/parser.c:7877
0x6517af cp_parser_assignment_expression
        ../../gcc/gcc/cp/parser.c:7996
0x651c04 cp_parser_assignment_expression
        ../../gcc/gcc/cp/parser.c:8046
0x651c04 cp_parser_constant_expression
        ../../gcc/gcc/cp/parser.c:8256
0x65193c cp_parser_assignment_expression
        ../../gcc/gcc/cp/parser.c:8015
0x653c93 cp_parser_expression
        ../../gcc/gcc/cp/parser.c:8158
0x65449e cp_parser_expression
        ../../gcc/gcc/cp/parser.c:8197
0x65449e cp_parser_expression_statement
        ../../gcc/gcc/cp/parser.c:9488
Please submit a full bug report, [etc.]

Without "-O" I get the following (IMHO bogus) error message:

bug.cc: In function 'void foo()':
bug.cc:4:5: error: cannot convert 'bool' to '__vector(2) int' in assignment
   v = v || v;
     ^

And in fact, if I modify the testcase according to the error message, I get
another ICE:

================================================
void foo()
{
  int v __attribute__((vector_size(8)));
  bool b = v || v;
}
================================================

bug.cc: In function 'void foo()':
bug.cc:1:6: error: vector comparison returning a boolean
 void foo()
      ^
vector(2) int
vector(2) int
if (v != { 0, 0 }) goto <D.2218>; else goto <D.2221>;
bug.cc:1:6: error: vector comparison returning a boolean
vector(2) int
vector(2) int
if (v != { 0, 0 }) goto <D.2218>; else goto <D.2219>;
bug.cc:1:6: internal compiler error: verify_gimple failed
0xb4007f verify_gimple_in_seq(gimple_statement_d*)
        ../../gcc/gcc/tree-cfg.c:4368
0x9854fc gimplify_body(tree_node*, bool)
        ../../gcc/gcc/gimplify.c:8799
0x985806 gimplify_function_tree(tree_node*)
        ../../gcc/gcc/gimplify.c:8884
0x81f4c7 analyze_function
        ../../gcc/gcc/cgraphunit.c:636
0x8207b4 analyze_functions
        ../../gcc/gcc/cgraphunit.c:1002
0x821ce9 finalize_compilation_unit()
        ../../gcc/gcc/cgraphunit.c:2260
0x625cc0 cp_write_global_declarations()
        ../../gcc/gcc/cp/decl2.c:4438
Please submit a full bug report, [etc.]

Btw, the same happens for the operator &&.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[reichelt at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code,
                   |                            |ice-on-valid-code,
                   |                            |rejects-valid
            Summary|Operator || and && broken   |[4.8/4.9 Regression]
                   |for vectors                 |Operator || and && broken
                   |                            |for vectors
      Known to fail|                            |4.8.0, 4.9.0

--- Comment #1 from Volker Reichelt <reichelt at gcc dot gnu.org> ---
This might be related to PR58809.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code,          |
                   |rejects-valid               |

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
See PR 54427, I wrote a patch to support && and || for vectors, but it wasn't
accepted. If we won't support them, we should explicitly reject them, this also
causes PR 57198.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I suppose we want ear (again) from Richard

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[reichelt at gcc dot gnu.org]

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

--- Comment #4 from Volker Reichelt <reichelt at gcc dot gnu.org> ---
Btw, clang 3.2 accepts the first code snippet and rejects the second one.
I.e. it accepts && and || for vectors and returns a vector of the same size.

IMHO GCC should also go for this route. Not because of clang, but because it
looks like the most natural thing (for me) to do here.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, what does OpenCL specify here?  IIRC we've decided on -1 (all bits set)
as true for vectors and 0 as false.  I'd prefer to allow trivial lowering
to | and & which IIRC are already supported.  That means that

 v1 && v2

should be emitted as GENERIC

 (v1 != { 0, 0, ... }) && (v2 != { 0, 0, ... })

where the ANDIF semantics don't make sense for vectors(?) and thus we
can directly emit GENERIC

 (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })

from the frontend.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If there are no side-effects in v1 or v2, why not, but if there are
side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 4 Nov 2013, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If there are no side-effects in v1 or v2, why not, but if there are
> side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.

Then I'd say leave the whole thing to gimplification.

Richard.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Well, what does OpenCL specify here?

"The logical operators and (&&), or (||) operate on all scalar and vector
built-in types.  For scalar built-in types only, and (&&) will only evaluate
the right hand operand if the left hand operand compares unequal to 0.  For
scalar built-in types only, or (||) will only evaluate the right hand operand
if the left hand operand compares equal to 0.  For built-in vector types, both
operands are evaluated and the operators are applied component-wise.  If one
operand is a scalar and the other is a vector, the scalar may be subject to the
usual arithmetic conversion to the element type used by the vector operand. The
scalar type is then widened to a vector that has the same number of components
as the vector operand. The operation is done component-wise resulting in the
same size vector.

The logical operator exclusive or (^^) is reserved.

The result is a scalar signed integer of type int if the source operands are
scalar and a vector signed integer type of the same size as the source operands
if the source operands are vector types. Vector source operands of type charn
and ucharn return a charn result; vector source operands of type shortn and
ushortn return a shortn result; vector source operands of type intn, uintn and
floatn return an intn result; vector source operands of type longn, ulongn and
doublen return a longn result.

For scalar types, the logical operators shall return 0 if the result of the
operation is false and 1 if the result is true. For vector types, the logical
operators shall return 0 if the result of the operation is false and -1 (i.e.
all bits set) if the result is true."

>  v1 && v2
> 
> should be emitted as GENERIC
> 
>  (v1 != { 0, 0, ... }) && (v2 != { 0, 0, ... })
> 
> where the ANDIF semantics don't make sense for vectors(?) and thus we
> can directly emit GENERIC
> 
>  (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })
> 
> from the frontend.

IIRC that's what the patch did:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00783.html

(In reply to Jakub Jelinek from comment #6)
> If there are no side-effects in v1 or v2, why not, but if there are
> side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.

What does ANDIF mean in this case? Only evaluate v2 if v1 has at least one
non-zero element? That still doesn't match the scalar version. Only evaluate
parts of v2? That doesn't seem possible.

(In reply to rguenther@suse.de from comment #7)
> Then I'd say leave the whole thing to gimplification.

And implement what semantics in gimplification?

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 4 Nov 2013, glisse at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
> 
> --- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #5)
> > Well, what does OpenCL specify here?
> 
> "The logical operators and (&&), or (||) operate on all scalar and vector
> built-in types.  For scalar built-in types only, and (&&) will only evaluate
> the right hand operand if the left hand operand compares unequal to 0.  For
> scalar built-in types only, or (||) will only evaluate the right hand operand
> if the left hand operand compares equal to 0.
>
>  For built-in vector types, both
> operands are evaluated and the operators are applied component-wise.  If one
> operand is a scalar and the other is a vector, the scalar may be subject to the
> usual arithmetic conversion to the element type used by the vector operand. The
> scalar type is then widened to a vector that has the same number of components
> as the vector operand. The operation is done component-wise resulting in the
> same size vector.

Thus no short-circuiting for vector && or ||.

> The logical operator exclusive or (^^) is reserved.
> 
> The result is a scalar signed integer of type int if the source operands are
> scalar and a vector signed integer type of the same size as the source operands
> if the source operands are vector types. Vector source operands of type charn
> and ucharn return a charn result; vector source operands of type shortn and
> ushortn return a shortn result; vector source operands of type intn, uintn and
> floatn return an intn result; vector source operands of type longn, ulongn and
> doublen return a longn result.
> 
> For scalar types, the logical operators shall return 0 if the result of the
> operation is false and 1 if the result is true. For vector types, the logical
> operators shall return 0 if the result of the operation is false and -1 (i.e.
> all bits set) if the result is true."
> 
> >  v1 && v2
> > 
> > should be emitted as GENERIC
> > 
> >  (v1 != { 0, 0, ... }) && (v2 != { 0, 0, ... })
> > 
> > where the ANDIF semantics don't make sense for vectors(?) and thus we
> > can directly emit GENERIC
> > 
> >  (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })
> > 
> > from the frontend.
> 
> IIRC that's what the patch did:
> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00783.html
> 
> (In reply to Jakub Jelinek from comment #6)
> > If there are no side-effects in v1 or v2, why not, but if there are
> > side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.
> 
> What does ANDIF mean in this case? Only evaluate v2 if v1 has at least one
> non-zero element? That still doesn't match the scalar version. Only evaluate
> parts of v2? That doesn't seem possible.

Yeah, exactly.  Still if there is a sequence point at && or ||
(even if both arms are always executed) then the order of evaluating
side-effects is important.  IIRC only AND/ORIF have an implicit
sequence point during gimplification.

> (In reply to rguenther@suse.de from comment #7)
> > Then I'd say leave the whole thing to gimplification.
> 
> And implement what semantics in gimplification?

No short-circuiting but preserving the sequence point (if there is one)

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #9)
> Thus no short-circuiting for vector && or ||.

Indeed. Though we already deviated from OpenCL for ?: and as mentioned in my
patch we could do short-circuit for the mixed scalar&&vector if we wanted to
(though we probably don't).

> No short-circuiting but preserving the sequence point (if there is one)

Ah, I'd completely missed that we might want a sequence point there, thanks, it
makes sense.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[rguenth at gcc dot gnu.org]

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

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

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

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-19
     Ever confirmed|0                           |1

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #9)
> Yeah, exactly.  Still if there is a sequence point at && or ||
> (even if both arms are always executed) then the order of evaluating
> side-effects is important.  IIRC only AND/ORIF have an implicit
> sequence point during gimplification.

We have avoided generating TRUTH_*_EXPR for vectors (at your request IIRC), so
I don't think we should produce some in the front-end now, even if temporarily,
as they would leak into fold-const.c. It seems easiest to save_expr the lhs and
build a compound_expr(lhs,*) to enforce the evaluation of the lhs first, I
think that gets us a sequence point as well.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yes, the comma operator is a sequence point.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 31343
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31343&action=edit
WIP

Let me attach this here. save_expr+build_vector_from_val is unnecessary, the
BIT_*_EXPR case would handle it. scalar&&vector is short-circuit (not
vector&&any), that's easy to change but it makes sense to me to have it
short-circuit since it is possible.

This is all untested and more stage1 material anyway.

And we will still need quite a few simple optimizations on vectors to get
sensible code out of it (things like (a<b)!=0 for instance).

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
>  (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })

FWIW this seems to be what clang does, without any kind of sequence point.

I'm not sure why fixing this would need to wait for stage 1; it looks to me
like your patch shouldn't affect the behavior of anything that currently works.
 I suppose figuring out what semantics we want is the important part.

I'm going to go ahead and fix the ICE to get the regression out of the way.

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Sat Mar  1 14:14:25 2014
New Revision: 208243

URL: http://gcc.gnu.org/viewcvs?rev=208243&root=gcc&view=rev
Log:
    PR c++/58845
    * typeck.c (cp_build_binary_op): Sorry on vector&&vector.

Added:
    trunk/gcc/testsuite/g++.dg/ext/vector27.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #15)
> (In reply to Richard Biener from comment #5)
> >  (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })
> 
> FWIW this seems to be what clang does, without any kind of sequence point.

Yes, and that's what OpenCL says, but since we have already started
diverging...

> I suppose figuring out what semantics we want is the important part.

Well, I am ok with the semantics of my patch (explained in comment #14) ;-)
(I would probably be ok with other versions as well though)

For the implementation, I have a slight preference for the #if 1 version in the
patch, but I am not sure if it is better (3 lines are unnecessary in the #else
version, so they both have the same size).

Also, some error messages could be surprising (talk about '==' when the program
uses '!'), but that's not the only place in the compiler where it happens.

> I'm going to go ahead and fix the ICE to get the regression out of the way.

Thanks!

[Bug c++/58845] [4.8/4.9 Regression] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Sat Mar  1 18:44:25 2014
New Revision: 208246

URL: http://gcc.gnu.org/viewcvs?rev=208246&root=gcc&view=rev
Log:
    PR c++/58845
    * typeck.c (cp_build_binary_op): Sorry on vector&&vector.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/vector27.C
Modified:
    branches/gcc-4_8-branch/gcc/cp/ChangeLog
    branches/gcc-4_8-branch/gcc/cp/typeck.c

[Bug c++/58845] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |rejects-valid
           Priority|P2                          |P3
   Target Milestone|4.8.3                       |---
            Summary|[4.8/4.9 Regression]        |Operator || and && broken
                   |Operator || and && broken   |for vectors
                   |for vectors                 |

--- Comment #19 from Jason Merrill <jason at gcc dot gnu.org> ---
No longer a regression.

[Bug c++/58845] Operator || and && broken for vectors

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jenkinsj89 at yahoo dot ca

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 60506 has been marked as a duplicate of this bug. ***

[Bug c++/58845] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845

--- Comment #21 from Marc Glisse <glisse at gcc dot gnu.org> ---
One argument against the sequence point is that we don't have one for ?: . If
we add one for ?: several testcases regress, so we have to make sure to only do
the save_expr/compound_expr thing if there are side effects, or port some more
fold-const optimizations to gimple (and update the testcases to check for the
optimization in a later dump).

[Bug c++/58845] Operator || and && broken for vectors

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845

--- Comment #22 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #21)
> One argument against the sequence point is that we don't have one for ?: .
> If we add one for ?: several testcases regress, so we have to make sure to
> only do the save_expr/compound_expr thing if there are side effects, or port
> some more fold-const optimizations to gimple (and update the testcases to
> check for the optimization in a later dump).

That seems like a fine reason not to diverge from the OpenCL semantics in this
case.

[Bug c++/58845] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845

--- Comment #23 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Fri Oct  3 19:57:01 2014
New Revision: 215872

URL: https://gcc.gnu.org/viewcvs?rev=215872&root=gcc&view=rev
Log:
2014-10-03  Marc Glisse  <marc.glisse@inria.fr>

    PR c++/54427
    PR c++/57198
    PR c++/58845
gcc/c-family/
    * c-common.c (warn_logical_operator): Punt for vectors.
gcc/cp/
    * typeck.c (cp_build_binary_op): save_expr after convert to save
    redundant operations.
    [TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR]: Handle vectors.
    (cp_build_unary_op) [TRUTH_NOT_EXPR]: Likewise.
gcc/
    * doc/extend.texi (Vector Extensions): Document &&, ||, ! in C++.
gcc/testsuite/
    * g++.dg/ext/vector9.C: Update, not an error anymore.
    * g++.dg/ext/vector27.C: Replace with new test.
    * g++.dg/ext/vector28.C: New file.
    * g++.dg/other/error23.C: Update to a different error.


Added:
    trunk/gcc/testsuite/g++.dg/ext/vector28.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c
    trunk/gcc/doc/extend.texi
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/ext/vector27.C
    trunk/gcc/testsuite/g++.dg/ext/vector9.C
    trunk/gcc/testsuite/g++.dg/other/error23.C

[Bug c++/58845] Operator || and && broken for vectors

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #24 from Marc Glisse <glisse at gcc dot gnu.org> ---
Now supported on trunk. If people later decide they want to add a sequence
point, I would suggest starting with ?: before looking at && and ||.