[Bug target/65284] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[Bug target/65284] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

            Bug ID: 65284
           Summary: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

r221115 on arm-linux-gnueabihf

$ g++ -std=c++11 -c -O2 schema-parser.ii 
schema-parser.ii: In member function 'Maybe<ParsedSchema>
ParsedSchema::findNested() const':
schema-parser.ii:45:21: internal compiler error: Segmentation fault
 Maybe<ParsedSchema> ParsedSchema::findNested() const {
                     ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ gdb --args /usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus -fpreprocessed
schema-parser.ii -quiet -dumpbase schema-parser.ii -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase
schema-parser -O2 -std=c++11 -version -fstack-protector-strong -Wformat
-Wformat-security -o /tmp/ccABpp5w.s

(gdb) bt
#0  0x00346d52 in maybe_canonicalize_mem_ref_addr(tree_node**) ()
#1  0x0034ee4c in fold_stmt_1(gimple_stmt_iterator*, bool, tree_node*
(*)(tree_node*)) ()
#2  0x0053bb56 in (anonymous namespace)::pass_forwprop::execute(function*) ()
#3  0x00434e5e in execute_one_pass(opt_pass*) ()
#4  0x00435148 in execute_pass_list_1(opt_pass*) [clone .constprop.59] ()
#5  0x00435152 in execute_pass_list_1(opt_pass*) [clone .constprop.59] ()
#6  0x00435180 in execute_pass_list(function*, opt_pass*) ()
#7  0x00298eb6 in cgraph_node::expand() ()
#8  0x0029a93c in symbol_table::compile() [clone .part.42] ()
#9  0x0029ab78 in symbol_table::finalize_compilation_unit() ()
#10 0x001a34e4 in cp_write_global_declarations() ()
#11 0x004aa082 in compile_file() ()
#12 0x001571a6 in toplev::main(int, char**) ()
#13 0x00157bf4 in main ()

$ cat schema-parser.ii
namespace _ {
template <typename T> class NullableValue {
public:
  T operator*();
  NullableValue(T);
};
}
template <typename T> class Maybe {
public:
  Maybe(T t) : ptr(t) {}
  template <typename Func> auto map(Func f) -> Maybe<decltype(f(T()))> {
    return f(*ptr);
  }
  _::NullableValue<T> ptr;
};
template <typename T> class A {
public:
  T *operator->();
};
typedef int uint64_t;
class B {
public:
  long getId();
};
class C {
  struct D;
  A<D> impl;
  friend class ParsedSchema;
};
class ParsedSchema {
  Maybe<ParsedSchema> findNested() const;
  ParsedSchema(ParsedSchema, C);
  C *parser;
  B getProto() const;
  int raw;
};
class F {
public:
  Maybe<uint64_t> lookup(uint64_t, int);
  ParsedSchema get(uint64_t);
};
struct C::D {
  F compiler;
};
Maybe<ParsedSchema> ParsedSchema::findNested() const {
  int name;
  parser->impl->compiler.lookup(getProto().getId(), name)
      .map([this](uint64_t childId) {
        return ParsedSchema(parser->impl->compiler.get(childId), *parser);
      });
}

[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-03-03
                 CC|                            |rguenth at gcc dot gnu.org
          Component|target                      |c++
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I get (on x86_64-linux):

./cc1plus  -quiet t.ii -std=c++11
t.ii: In lambda function:
t.ii:50:7: error: using result of function returning 'void'
       });
       ^

so assuming the testcase is valid this is a C++ rejects-valid bug now
(4.9 accepts it)?

and with a cross to arm:

> ./cc1plus  -quiet -std=c++11 ../../trunk-g/gcc/t.ii -I include
../../trunk-g/gcc/t.ii: In lambda function:
../../trunk-g/gcc/t.ii:48:30: error: non-trivial conversion at assignment
  .map([this](uint64_t childId) {
                              ^
struct ParsedSchema
struct ParsedSchema *
<retval> = D.4929;
../../trunk-g/gcc/t.ii:48:30: internal compiler error: verify_gimple failed
0xf83713 verify_gimple_in_seq(gimple_statement_base*)
        /space/rguenther/src/svn/trunk2/gcc/tree-cfg.c:4736
0xcb9d25 gimplify_body(tree_node*, bool)

do you have checking disabled?

[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #2 from Matthias Klose <doko at gcc dot gnu.org> ---
> do you have checking disabled?

configured with --enable-checking=release

[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2015-03-03 00:00:00         |2015-03-04
                 CC|                            |aldyh at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed with --enable-checking=release and a cross build:

$ ./cc1plus a.ii -quiet -std=c++11 -I./ -O2
a.ii: In member function ‘Maybe<ParsedSchema> ParsedSchema::findNested()
const’:
a.ii:45:21: internal compiler error: Segmentation fault
 Maybe<ParsedSchema> ParsedSchema::findNested() const {


I'll take a look.
>From gcc-bugs-return-479355-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 04 16:37:47 2015
Return-Path: <gcc-bugs-return-479355-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14266 invoked by alias); 4 Mar 2015 16:37:47 -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 14190 invoked by uid 48); 4 Mar 2015 16:37:43 -0000
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
Date: Wed, 04 Mar 2015 16:37: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65298-4-XClnPw2kHX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65298-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65298-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: 2015-03/txt/msg00499.txt.bz2
Content-length: 2712

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide298

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #3)
> ix=1 and m_vecpfx.m_num=1 in this case.
> Let me know what other debugging info may be useful to you.

Well, it might be difficult debugging this without reproducing it,
but...

It would be nice to know, at ipa-cp.c:937, what is the
IPA_NODE_REF(parms_info->ipcp_orig_node), especially the lengths of
the descriptors and lattices vectors.  IPA_NODE_REF currently
translates to ipa_node_params_sum->get(parms_info->ipcp_orig_node) so
it should be easily printable in gdb.

Also, at ipa-inline-analysis.c:950, it is important to know where
parms_info came from, i.e. whether it was obtained as IPA_NODE_REF
(e->caller->global.inlined_to) or only IPA_NODE_REF (e->caller).

You might also try running with the following patch which should
hopefully find out where we create the first wrong jump function
(assuming that is the problem):

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index cfd9c16..7116c0f 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -2570,6 +2570,12 @@ update_jump_functions_after_inlining (struct cgraph_edge
*cs,
                    enum tree_code operation;
                    operation = ipa_get_jf_pass_through_operation (src);

+                   struct ipa_node_params *new_root_info;
+                   new_root_info = IPA_NODE_REF (cs->caller->global.inlined_to
+                                                 ?
cs->caller->global.inlined_to
+                                                 : cs->caller);
+                   gcc_assert (formal_id < ipa_get_param_count
(new_root_info));
+
                    if (operation == NOP_EXPR)
                      {
                        bool agg_p;
@@ -4570,6 +4576,8 @@ ipa_read_jump_function (struct lto_input_block *ib,
       if (operation == NOP_EXPR)
        {
          int formal_id =  streamer_read_uhwi (ib);
+         gcc_assert (formal_id
+                     < ipa_get_param_count (IPA_NODE_REF (cs->caller)));
          struct bitpack_d bp = streamer_read_bitpack (ib);
          bool agg_preserved = bp_unpack_value (&bp, 1);
          ipa_set_jf_simple_pass_through (jump_func, formal_id, agg_preserved);
@@ -4578,6 +4586,8 @@ ipa_read_jump_function (struct lto_input_block *ib,
        {
          tree operand = stream_read_tree (ib, data_in);
          int formal_id =  streamer_read_uhwi (ib);
+         gcc_assert (formal_id
+                     < ipa_get_param_count (IPA_NODE_REF (cs->caller)));
          ipa_set_jf_arith_pass_through (jump_func, formal_id, operand,
                                         operation);
        }

[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[aldyh at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 8085 bytes --]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
This was caused by r210292:

commit f1ec53b67367cb5d4aba65b5648e5faa5f29bdf0
Author: jason <jason@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri May 9 20:07:45 2014 +0000

        PR c++/60463
        PR c++/60755
        * lambda.c (lambda_expr_this_capture): Add new parameter
        add_capture_p controlling whether the functions will try to
        capture 'this' via the default capture.
        (maybe_resolve_dummy): Likewise.
        * cp-tree.h: Adjust prototypes.
        * call.c, semantics.c: Change callers of these functions.
        * call.c (build_new_method_call_1): Use the actual 'this' that
        would be potentially captured for the overload resolution, instead
        of the dummy object.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210292
138bc75d-0d04-0410-961f-82ee72b054a4

Jason, just so I know what I'm looking at here, is the testcase even valid? 
Because mainline on x86-64 has a totally different symptom than ppc with
--enable-checking and a totally different symptom than ppc with
--enable-checking=release.

On mainline on x86-64 (with either default checking or
--enable-checking=release), we get:

reynosa:/build/t/gcc$ ./cc1plus ~/a.ii -quiet -std=c++11 -O2 -I./
/home/aldyh/a.ii: In lambda function:
/home/aldyh/a.ii:50:7: error: using result of function returning ‘void’
       });

On a cross PPC with default checking we get:

reynosa:/build/arm-linux-gnueabihf-checking/gcc$ ./cc1plus ~/a.ii -quiet
-std=c++11 -O2 -I./ 
/home/aldyh/a.ii: In lambda function:
/home/aldyh/a.ii:48:35: error: non-trivial conversion at assignment
       .map([this](uint64_t childId) {
                                   ^
struct ParsedSchema
struct ParsedSchema *
<retval> = D.4925;
/home/aldyh/a.ii:48:35: internal compiler error: verify_gimple failed
0xf4da3b verify_gimple_in_seq(gimple_statement_base*)
    /source/gcc/gcc/tree-cfg.c:4736
0xc7fe6d gimplify_body(tree_node*, bool)
    /source/gcc/gcc/gimplify.c:9117
0xc802a7 gimplify_function_tree(tree_node*)
    /source/gcc/gcc/gimplify.c:9202
0xa2f3e0 cgraph_node::analyze()
    /source/gcc/gcc/cgraphunit.c:633
0xa306ba analyze_functions
    /source/gcc/gcc/cgraphunit.c:1023
0xa34a5f symbol_table::finalize_compilation_unit()
    /source/gcc/gcc/cgraphunit.c:2435
0x799173 cp_write_global_declarations()
    /source/gcc/gcc/cp/decl2.c:4754
Please submit a full bug report,

Finally, on a cross PPC with --enable-checking=release we get:

reynosa:/build/arm-linux-gnueabihf/gcc$ ./cc1plus ~/a.ii -quiet -std=c++11 -O2
-I./ 
/home/aldyh/a.ii: In member function ‘Maybe<ParsedSchema>
ParsedSchema::findNested() const’:
/home/aldyh/a.ii:45:21: internal compiler error: Segmentation fault
 Maybe<ParsedSchema> ParsedSchema::findNested() const {
                     ^
0xd1b9a4 crash_signal
    /source/gcc/gcc/toplev.c:383
0xa40122 maybe_canonicalize_mem_ref_addr
    /source/gcc/gcc/gimple-fold.c:3504
0xa402c3 fold_stmt_1
    /source/gcc/gcc/gimple-fold.c:3556
0xa40e07 fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*))
    /source/gcc/gcc/gimple-fold.c:3810
0xe438c7 execute
    /source/gcc/gcc/tree-ssa-forwprop.c:2347
Please submit a full bug report,

Odd indeed.  A little guidance would be appreciated, as I don't even know which
one of the three is the correct path.
>From gcc-bugs-return-479381-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 04 20:03:39 2015
Return-Path: <gcc-bugs-return-479381-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 120223 invoked by alias); 4 Mar 2015 20:03:39 -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 120117 invoked by uid 48); 4 Mar 2015 20:03:35 -0000
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65302] [5 Regression] LTO: ICE internal compiler error: verify_flow_info failed
Date: Wed, 04 Mar 2015 20:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-65302-4-RWBpEBDpAi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65302-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65302-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: 2015-03/txt/msg00525.txt.bz2
Content-length: 2455

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide302

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-04
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |richard.guenther at gmail dot com
     Ever confirmed|0                           |1

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed.  Happens during ltrans stage:

(gdb) bt
#0  internal_error (gmsgid=0x161bb98 "verify_flow_info failed")
    at /source/gcc/gcc/diagnostic.c:1221
#1  0x0000000000729a78 in verify_flow_info () at /source/gcc/gcc/cfghooks.c:280
#2  0x0000000000b3e1b5 in execute_function_todo (fn=0x7fffeff972a0, data=0x40)
    at /source/gcc/gcc/passes.c:1969
#3  0x0000000000b3d25e in do_per_function (callback    0xb3dfa3 <execute_function_todo(function*, void*)>, data=0x40)
    at /source/gcc/gcc/passes.c:1649
#4  0x0000000000b3e32f in execute_todo (flagsd)
    at /source/gcc/gcc/passes.c:2014
#5  0x0000000000b3ed09 in execute_one_pass (pass    <opt_pass* 0x2006480 "*free_cfg_annotations"(0)>)
    at /source/gcc/gcc/passes.c:2341
#6  0x0000000000b3eeb1 in execute_pass_list_1 (
    pass=<opt_pass* 0x2006480 "*free_cfg_annotations"(0)>)
    at /source/gcc/gcc/passes.c:2380
#7  0x0000000000b3ef1f in execute_pass_list (fn=0x7fffeff972a0,
    pass=<opt_pass* 0x2006480 "*free_cfg_annotations"(0)>)
    at /source/gcc/gcc/passes.c:2391
#8  0x0000000000763888 in cgraph_node::expand (
    this=<cgraph_node* 0x7fffeff99188 "Init">)
    at /source/gcc/gcc/cgraphunit.c:1878
#9  0x00000000007642f6 in output_in_order (no_reorderúlse)
    at /source/gcc/gcc/cgraphunit.c:2116
#10 0x00000000007649c3 in symbol_table::compile (this=0x7ffff018f000)
    at /source/gcc/gcc/cgraphunit.c:2361
#11 0x00000000006a5c0a in lto_main () at /source/gcc/gcc/lto/lto.c:3476
#12 0x0000000000c3750a in compile_file () at /source/gcc/gcc/toplev.c:594
#13 0x0000000000c399d3 in do_compile () at /source/gcc/gcc/toplev.c:2066
#14 0x0000000000c39c01 in toplev::main (this=0x7fffffffdbb0, argc%,
    argv=0x1fe0320) at /source/gcc/gcc/toplev.c:2164
#15 0x0000000001576ac7 in main (argc%, argv=0x7fffffffdcb8)
    at /source/gcc/gcc/main.c:39

[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 34959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34959&action=edit
reduced testcase

[Bug c++/65284] [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
For the construction of the lambda in the simplified testcase I have just
uploaded:

  MaybeInt().xmap([abc](int childId)
          {
            return ParsedSchema(bark, childId + 666);
          });

We initially generate the following tree:

ParsedSchema::findNested()::<lambda(int)> (const struct __lambda0 * const
__closure, int childId)
{
  const int abc [value-expr: __closure->__abc];

  <<cleanup_point return D.2331 = <<< Unknown tree: aggr_init_expr
  6
  __comp_ctor 
  *NON_LVALUE_EXPR <this>
  NON_LVALUE_EXPR <this>
  *NON_LVALUE_EXPR <this> = bark;, <<< Unknown tree: empty_class_expr >>>;
  childId + 666 >>>>>;
}

Whose AGGR_INIT_EXPR will be gimplified into:

ParsedSchema::findNested()::<lambda(int)> (const struct __lambda0 * const
__closure, int childId)
{
  const int abc [value-expr: __closure->__abc];

  <<cleanup_point return D.2331 = ParsedSchema::ParsedSchema (&*NON_LVALUE_EXPR
<this>, *NON_LVALUE_EXPR <this> = bark;, <<< Unknown tree: empty_class_expr
>>>;, childId + 666)>>;
}

Notice the non-existent return value from ParsedSchema::ParsedSchema is being
read from, and constructors do not return anything.  I suppose D.2331 should be
set from NON_LVALUE_EXPR<this>, although even the assignment into
*NON_LVALUE_EXPR looks odd.  Isn't a NON_LVALUE_EXPR by definition not
assignable?

Before the patch that broke this, we had:

  <<cleanup_point return <retval> = TARGET_EXPR <D.2133, <<< Unknown tree:
aggr_init_expr
  6
  __comp_ctor 
  D.2133
  (struct ParsedSchema *) 0
  TARGET_EXPR <D.2123, bark>;, <<< Unknown tree: empty_class_expr >>>;
  childId + 666 >>>>;, D.2133>>;

Notice the TARGET_EXPR, which then does the right thing when gimplified.

[Bug c++/65284] [5 Regression] C++ lambda and auto return value causes ICE or gimple error

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34959|0                           |1
        is obsolete|                            |

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 34977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34977&action=edit
smaller and simpler testcase

In cp_simplify_init_expr(), we are lowering part of the return
statement for the lambda function from this:

*NON_LVALUE_EXPR <this> = TARGET_EXPR <D.2173, <<< Unknown tree: aggr_init_expr
  4
  __comp_ctor 
  D.2173
  NON_LVALUE_EXPR <this> >>>>;

into:

<<< Unknown tree: aggr_init_expr
  4
  __comp_ctor 
  *NON_LVALUE_EXPR <this>        <-- notice we've dropped D.2173
  NON_LVALUE_EXPR <this> >>>;

This last blob cannot be stored into retval because the value of the
aggr_init_expr is a read from the constructor which has a void return type.

[Bug c++/65284] [5 Regression] C++ lambda and auto return value causes ICE or gimple error

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug c++/65284] [5 Regression] C++ lambda and auto return value causes ICE or gimple error

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Fixed on mainline by Jason's fix to PR c++/65339.  Thanks.

*** This bug has been marked as a duplicate of bug 65339 ***