[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 ‘MaybeParsedSchema ParsedSchema::findNested()
const’:
a.ii:45:21: internal compiler error: Segmentation fault
 MaybeParsedSchema ParsedSchema::findNested() const {


I'll take a look.

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

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 ‘MaybeParsedSchema
ParsedSchema::findNested() const’:
/home/aldyh/a.ii:45:21: internal compiler error: Segmentation fault
 MaybeParsedSchema 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.

[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_EXPRthis, 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] 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=34959action=edit
reduced testcase

[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

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