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.
