[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
----------------------------------------------------------------------------
                 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.