[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

2018-03-21 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 21 20:19:33 2018
New Revision: 258741

URL: https://gcc.gnu.org/viewcvs?rev=258741=gcc=rev
Log:
PR c++/84961
* cp-tree.h (genericize_compound_lvalue): Declare.
* typeck.c (genericize_compound_lvalue): New function.
(unary_complex_lvalue, cp_build_modify_expr): Use it.
* semantics.c (finish_asm_stmt): Replace MODIFY_EXPR, PREINCREMENT_EXPR
and PREDECREMENT_EXPR in output and "m" constrained input operands with
COMPOUND_EXPR.  Call cxx_mark_addressable on the rightmost
COMPOUND_EXPR operand.

* c-c++-common/pr43690.c: Don't expect errors on "m" (--x) and
"m" (++x) in C++.
* g++.dg/torture/pr84961-1.C: New test.
* g++.dg/torture/pr84961-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr84961-1.C
trunk/gcc/testsuite/g++.dg/torture/pr84961-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr43690.c

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

2018-03-20 Thread rguenther at suse dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 20 Mar 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 43716
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43716=edit
> gcc8-pr84961.patch
> 
> So like this?

Yes.

> Or of course the gimplifier could do it too.

Sure, I tried and it looks somewhat awkward to teach it this.  Is
a MODIFY_EXPR in GENERIC considered an lvalue?  I think not.

> The second testcase passed e.g. with 4.4, but fails already with 4.6, the 
> first
> one regressed later with the SSA_NAME gimplification.

Yeah, I think pre SSA_NAME gimplification we'd just generate wrong-code
eventually and not notice.

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

2018-03-20 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43716=edit
gcc8-pr84961.patch

So like this?  Or of course the gimplifier could do it too.
The second testcase passed e.g. with 4.4, but fails already with 4.6, the first
one regressed later with the SSA_NAME gimplification.

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

2018-03-20 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961

--- Comment #3 from Jakub Jelinek  ---
Doesn't ICE with C, where it is rejected with:
pr84961.c: In function ‘foo’:
pr84961.c:3:15: error: lvalue required in asm statement
 void foo () { asm("" : "=a"(b = a)); }
   ^~~
pr84961.c:3:15: error: invalid lvalue in asm output 0
But in C++ b = a seems to be considered as lvalue.
Let me have a look...

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

2018-03-20 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P2
 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
So we do

  tret = gimplify_expr (_VALUE (link), pre_p, post_p,
is_inout ? is_gimple_min_lval : is_gimple_lvalue,
fb_lvalue | fb_mayfail);

and gimplify b = (double) a to _3 with is_gimple_lvalue.  Which it isn't
here (the predicate returns true though).

With a similar

int main()
{
  int a,b,c;
  (b = c) = a;
}

the FE already replaces this with <> so it doesn't reach
gimplification.  It seems it expects the gimplifier to do this here.

Note the C FE complains:

t.c: In function ‘c’:
t.c:3:12: error: lvalue required in asm statement
 void c() { asm("" : "=a"(b = a)); }
^~~

but still throws the invalid asm at the gimplifier.  The C++ FE fails to
complain, but I guess (b = a) is an lvalue for C++?  In which case the
testcase would be valid C++ but invalid C?  G++ 6 accepts it.

The above testcase is genericized to

  <;

but the asm stays

<>;

I think the C++ FE should help us here by genericizing to b = (double) a; b?

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

2018-03-20 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||6.4.0
   Target Milestone|--- |7.4
Summary|internal compiler error:|[7/8 Regression] ICE error:
   |verify_ssa failed   |SSA_NAME_DEF_STMT is wrong
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r235817.