Bug 69889 - [6 Regression] ICE: in assign_temp, at function.c:961
Summary: [6 Regression] ICE: in assign_temp, at function.c:961
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 6.0
: P1 normal
Target Milestone: 6.0
Assignee: Jason Merrill
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-21 10:42 UTC by Benjamin Bannier
Modified: 2016-02-27 13:10 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-02-22 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Bannier 2016-02-21 10:42:27 UTC 
I see an internal compiler error with the following code (reduced from actual production code that passes with g++-5.3.0).

% cat log.ii
template <typename F> struct Tag {
  static void fp() { f()(0); }
  static F f() {}
};

struct Dispatch {
  template <typename F> Dispatch(F&&) : f(Tag<F>::fp) {}
  void (*f)();
};

struct Empty { Empty(Empty&&); };

struct Value {
  Value();
  template <typename U> Value(U);
  void call(Dispatch);
  Empty e;
};

struct EmptyValue {
  EmptyValue(EmptyValue&&);
  EmptyValue();
};

struct User {
  User() {
    Value().call([](Value) { return EmptyValue(); });
  }
};

User user;


% g++ --std=c++11 -S log.ii
log.ii: In static member function ‘static EmptyValue User::User()::<lambda(Value)>::_FUN(Value)’:
log.ii:27:51: internal compiler error: in assign_temp, at function.c:961
     Value().call([](Value) { return EmptyValue(); });
                                                   ^

log.ii:27:51: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 Jakub Jelinek 2016-02-22 08:45:08 UTC 
Started with r232168.
Comment 2 Jakub Jelinek 2016-02-23 16:20:31 UTC 
This looks like a C++ FE bug to me, the operator() method is called with TREE_ADDRESSABLE argument by value, rather than by reference.
Normally, when the C++ FE goes through build_over_call, convert_for_arg_passing (or earlier code) should change those arguments to reference passing.
On this testcase the call is generated from simplify_aggr_init_expr, and is passed by value instead.  I don't know the FE enough to know if it should be already aggr_init_expr AGGR_INIT_EXPR_ARGP argument to be actually the reference, or if it is a simplify_aggr_init_expr bug.
Jason, can you please have a look?
Comment 3 Jason Merrill 2016-02-25 16:23:11 UTC 
(In reply to Jakub Jelinek from comment #1)
> Started with r232168.

I don't think so; reverting that commit doesn't change anything.
Comment 4 Marek Polacek 2016-02-25 16:29:17 UTC 
Not r232168 but r232167 it seems.
Comment 5 Jason Merrill 2016-02-26 04:54:31 UTC 
Author: jason
Date: Fri Feb 26 04:53:58 2016
New Revision: 233733

URL: https://gcc.gnu.org/viewcvs?rev=233733&root=gcc&view=rev
Log:
	PR c++/69889

	* cp-tree.h (AGGR_INIT_FROM_THUNK_P): New.
	* tree.c (build_aggr_init_expr): Set it.
	* semantics.c (simplify_aggr_init_expr): Check it.
	* cp-gimplify.c (cp_genericize_r): Don't walk into
	a call/aggr_init from a thunk.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-gimplify.c
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/semantics.c
    trunk/gcc/cp/tree.c
Comment 6 Jakub Jelinek 2016-02-26 14:26:55 UTC 
Fixed.
Comment 7 Benjamin Bannier 2016-02-27 13:10:20 UTC 
Thanks for taking care of this so quickly. I currently do not observe any more ICEs from that codebase.