User account creation filtered due to spam.

Bug 53696 - [4.8/4.9/4.10 Regression] ICE: SIGSEGV in gimplify_decl_expr (gimplify.c:1454) with -fkeep-inline-functions on invalid use of lambda
Summary: [4.8/4.9/4.10 Regression] ICE: SIGSEGV in gimplify_decl_expr (gimplify.c:1454...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.8.0
: P2 normal
Target Milestone: 4.8.4
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2012-06-16 12:01 UTC by Zdenek Sojka
Modified: 2014-06-13 18:40 UTC (History)
3 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build:
Known to work: 4.6.4
Known to fail: 4.7.2, 4.8.0
Last reconfirmed: 2012-06-16 00:00:00


Attachments
preprocessed source (138 bytes, application/octet-stream)
2012-06-16 12:01 UTC, Zdenek Sojka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zdenek Sojka 2012-06-16 12:01:49 UTC
Created attachment 27631 [details]
preprocessed source

Compiler output:
$ gcc -fkeep-inline-functions testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C 
testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C: In function 'void foo(A&)':
testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C:8:3: error: invalid use of incomplete type 'struct A'
   [=](){a;};      // { dg-error "invalid use of incomplete type" }
   ^
testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C:4:8: error: forward declaration of 'struct A'
 struct A;         // { dg-error "forward declaration" }
        ^
testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C:8:11: warning: lambda expressions only available with -std=c++11 or -std=gnu++11 [enabled by default]
   [=](){a;};      // { dg-error "invalid use of incomplete type" }
           ^
testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C: In lambda function:
testsuite/g++.dg/cpp0x/lambda/lambda-ice7.C:8:9: internal compiler error: Segmentation fault
   [=](){a;};      // { dg-error "invalid use of incomplete type" }
         ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


(gdb) bt
#0  0x00000000009e3961 in gimplify_decl_expr (seq_p=0x7fffffffd1b8, stmt_p=0x7ffff5bf0b20) at /mnt/svn/gcc-trunk/gcc/gimplify.c:1454
#1  gimplify_expr (expr_p=0x7ffff5bf0b20, pre_p=0x7fffffffd1b8, post_p=0x7fffffffcf18, gimple_test_f=<optimized out>, fallback=<optimized out>)
    at /mnt/svn/gcc-trunk/gcc/gimplify.c:7312
#2  0x00000000009e6627 in gimplify_stmt (stmt_p=<optimized out>, seq_p=0x7fffffffd1b8) at /mnt/svn/gcc-trunk/gcc/gimplify.c:5678
#3  0x00000000009e138c in gimplify_statement_list (pre_p=0x7fffffffd1b8, expr_p=0x7ffff5bf9060) at /mnt/svn/gcc-trunk/gcc/gimplify.c:1528
#4  gimplify_expr (expr_p=0x7ffff5bf9060, pre_p=0x7fffffffd1b8, post_p=0x7fffffffd098, gimple_test_f=<optimized out>, fallback=<optimized out>)
    at /mnt/svn/gcc-trunk/gcc/gimplify.c:7531
#5  0x00000000009e6627 in gimplify_stmt (stmt_p=<optimized out>, seq_p=0x7fffffffd1b8) at /mnt/svn/gcc-trunk/gcc/gimplify.c:5678
#6  0x00000000009e75b4 in gimplify_bind_expr (expr_p=0x7ffff5be7598, pre_p=<optimized out>) at /mnt/svn/gcc-trunk/gcc/gimplify.c:1222
#7  0x00000000009e1bad in gimplify_expr (expr_p=0x7ffff5be7598, pre_p=0x7fffffffd3a8, post_p=0x7fffffffd288, gimple_test_f=<optimized out>, 
    fallback=<optimized out>) at /mnt/svn/gcc-trunk/gcc/gimplify.c:7316
#8  0x00000000009e6627 in gimplify_stmt (stmt_p=<optimized out>, seq_p=0x7fffffffd3a8) at /mnt/svn/gcc-trunk/gcc/gimplify.c:5678
#9  0x00000000009f56a2 in gimplify_body (fndecl=0x7ffff5be7500, do_parms=<optimized out>) at /mnt/svn/gcc-trunk/gcc/gimplify.c:8177
#10 0x00000000009f5b4e in gimplify_function_tree (fndecl=0x7ffff5be7500) at /mnt/svn/gcc-trunk/gcc/gimplify.c:8311
#11 0x0000000000854358 in cgraph_analyze_function (node=0x7ffff5a80750) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:652
#12 0x00000000008568cd in cgraph_analyze_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:938
#13 0x0000000000857b31 in finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2086
#14 0x0000000000676a2b in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:4024
#15 0x0000000000b944ac in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:566
#16 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1870
#17 toplev_main (argc=14, argv=0x7fffffffd6e8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1946
#18 0x00007ffff61b62ad in __libc_start_main () from /lib64/libc.so.6
#19 0x0000000000597d21 in _start ()


Tested revisions:
r188682 - crash
4.7 r188682 - crash
4.6 r188682 - OK
Comment 1 H.J. Lu 2012-06-16 17:48:52 UTC
It is caused by revision 185722:

http://gcc.gnu.org/ml/gcc-cvs/2012-03/msg01052.html
Comment 2 Paolo Carlini 2012-09-07 08:35:41 UTC
Bah, in my opinion ranking P2 an ice on invalid after meaningful diagnostics, which moreover happens on a testcase which used to ice anyway before my patch, only, without the keep-inline-functions on the command line, doesn't look right. Anyway, I'll see what I can do, for .0 we may have to revert my patch.
Comment 3 Jakub Jelinek 2012-09-20 10:19:02 UTC
GCC 4.7.2 has been released.
Comment 4 Jakub Jelinek 2012-12-07 15:54:22 UTC
And
struct A;

template <int N>
void foo(A& a)
{
  [=](){a;};
}

void
bar (A&a)
{
  foo<6>(a);
}

ICEs even without -fkeep-inline-functions elsewhere.
I wonder if
  else
    /* Capture by copy requires a complete type.  */
    type = complete_type (type);
in semantics.c (add_capture) shouldn't be something like:
--- cp/semantics.c.jj	2012-12-06 21:33:57.000000000 +0100
+++ cp/semantics.c	2012-12-07 16:45:30.000000000 +0100
@@ -9164,7 +9164,14 @@ add_capture (tree lambda, tree id, tree
     }
   else
     /* Capture by copy requires a complete type.  */
-    type = complete_type (type);
+    {
+      if (processing_template_decl)
+	type = complete_type (type);
+      else
+	type = complete_type_or_else (type, initializer);
+      if (type == NULL_TREE)
+	type = error_mark_node;
+    }
 
   /* Add __ to the beginning of the field name so that user code
      won't find the field with name lookup.  We can't just leave the name

This fixes the ICE in #c0 (but we error twice for the incomplete type, once within the lambda, once within the parent function).
For templates it of course doesn't change anything, we I think generally can't require the type to be complete there, so it must be done later during pt.c.
Comment 5 Paolo Carlini 2012-12-07 16:20:35 UTC
If you want me to revert that patchlet of mine don't be afraid to ask, after all was just an ice on invalid, no big deal. Can do that immediately and then we have all the time to figure out something better with no fear of regressions, even minor.
Comment 6 Jakub Jelinek 2012-12-07 16:27:14 UTC
(In reply to comment #5)
> If you want me to revert that patchlet of mine don't be afraid to ask, after
> all was just an ice on invalid, no big deal. Can do that immediately and then
> we have all the time to figure out something better with no fear of
> regressions, even minor.

This is also an ice-on-invalid, so trading one for another one doesn't buy us much.  And, don't we ICE for the testcase with template anyway?
Comment 7 Richard Biener 2013-04-11 07:59:24 UTC
GCC 4.7.3 is being released, adjusting target milestone.
Comment 8 Richard Biener 2014-06-12 13:46:38 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 9 Paolo Carlini 2014-06-13 14:03:15 UTC
By the way, in mainline I can't reproduce this anymore.
Comment 10 Jason Merrill 2014-06-13 18:40:57 UTC
Can't reproduce on the current 4.8 or 4.9 branch either.  Closing.