[Bug middle-end/64465] New: [5 Regression] internal compiler error: verify_flow_info failed

[Bug middle-end/64465] New: [5 Regression] internal compiler error: verify_flow_info failed

[hjl.tools at gmail dot com]

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

            Bug ID: 64465
           Summary: [5 Regression] internal compiler error:
                    verify_flow_info failed
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com

On Linux/x86-64, r219127 gave:

[hjl@gnu-tools-1 tmp]$ cat foo.c
typedef void (*__sighandler_t) (int);
struct sigaction
  {
 __sighandler_t sa_handler;
  };
extern int sigaction (const struct sigaction *__restrict __act);
extern int __open_alias (const char *__path, int __oflag, ...) __asm__ (""
"open")
                              ;
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) int
open (const char *__path, int __oflag, ...)
{
  if (__builtin_constant_p (__oflag))
    return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
  return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
}
extern int close(int fd);
static void
set_fortify_handler (void (*handler) (int sig))
{
  struct sigaction sa;
  sigaction (&sa);
  int fd = open ("/dev/null", 3);
  if (fd == -1)
    close (1);
}
extern void handler (int sig);
void
do_test (void)
{
  set_fortify_handler (handler);
}
[hjl@gnu-tools-1 tmp]$
/export/build/gnu/gcc-x32/release/usr/gcc-5.0.0-x32/bin/gcc -O2 foo.c   -O2
-Wall -fexceptions  
foo.c: In function ‘set_fortify_handler’:
foo.c:31:1: error: BB 5 last statement has incorrectly set lp
 }
 ^
foo.c:31:1: internal compiler error: verify_flow_info failed
0x71e49b verify_flow_info()
    /export/gnu/import/git/gcc/gcc/cfghooks.c:271
0xb33b39 cleanup_tree_cfg_noloop
    /export/gnu/import/git/gcc/gcc/tree-cfgcleanup.c:753
0xb33b39 cleanup_tree_cfg()
    /export/gnu/import/git/gcc/gcc/tree-cfgcleanup.c:802
0xa32b14 execute_function_todo
    /export/gnu/import/git/gcc/gcc/passes.c:1893
0xa33603 execute_todo
    /export/gnu/import/git/gcc/gcc/passes.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-472016-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 01 16:15:26 2015
Return-Path: <gcc-bugs-return-472016-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19519 invoked by alias); 1 Jan 2015 16:15:26 -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 19494 invoked by uid 48); 1 Jan 2015 16:15:21 -0000
From: "ville.voutilainen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64466] New: A generic lambda in a class template causes an ICE in gimplify
Date: Thu, 01 Jan 2015 16:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ville.voutilainen at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cc
Message-ID: <bug-64466-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-01/txt/msg00010.txt.bz2
Content-length: 3010

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

            Bug ID: 64466
           Summary: A generic lambda in a class template causes an ICE in
                    gimplify
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ville.voutilainen at gmail dot com
                CC: jason at redhat dot com

template<typename T> struct my_queue {
    void push(T){ }
    void ice(){ trav([&](auto &&v){ push(v); }); }
    template<typename F> void trav(F &&f){ f(T()); }
};
template class my_queue<int>;

Clang accepts the code. gcc ICEs:

lhmouse2.cpp: In lambda function:
lhmouse2.cpp:3:41: internal compiler error: Segmentation fault
     void ice(){ trav([&](auto &&v){ push(v); }); }
                                         ^
0xca552f crash_signal
        ../../gcc/toplev.c:358
0xa009f8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
        ../../gcc/tree.h:2892
0xa009f8 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
        ../../gcc/fold-const.c:1735
0xabfa04 gimplify_compound_lval
        ../../gcc/gimplify.c:2012
0xab7619 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gimplify.c:7686
0xac19af gimplify_call_expr
        ../../gcc/gimplify.c:2449
0xab790f gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gimplify.c:7705
0xabbe16 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gimplify.c:5473
0xab80ee gimplify_cleanup_point_expr
        ../../gcc/gimplify.c:5249
0xab80ee gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gimplify.c:8097
0xabbe16 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gimplify.c:5473
0xabccb5 gimplify_bind_expr
        ../../gcc/gimplify.c:1110
0xab78ed gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../gcc/gimplify.c:7931
0xabbe16 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../gcc/gimplify.c:5473
0xabd775 gimplify_body(tree_node*, bool)
        ../../gcc/gimplify.c:8843
0xabdd76 gimplify_function_tree(tree_node*)
        ../../gcc/gimplify.c:8996
0x903397 cgraph_node::analyze()
        ../../gcc/cgraphunit.c:613
0x905c57 analyze_functions
        ../../gcc/cgraphunit.c:1001
0x906855 symbol_table::finalize_compilation_unit()
        ../../gcc/cgraphunit.c:2351
0x6e3a8b cp_write_global_declarations()
        ../../gcc/cp/decl2.c:4742
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-01
                 CC|                            |hubicka at ucw dot cz
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It is caused by r219108.  The updated testcase:

[hjl@gnu-mic-2 gcc-regression]$ cat pr64465.c
typedef void (*__sighandler_t) (int);
struct sigaction
  {
 __sighandler_t sa_handler;
  };
extern int sigaction (const struct sigaction *__restrict __act);
extern int __open_alias (const char *__path, int __oflag, ...) __asm__ (""
"open")
                              ;
static __inline
__attribute__ ((__always_inline__))
int
open (const char *__path, int __oflag, ...)
{
  if (__builtin_constant_p (__oflag))
    return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
  return __open_alias (__path, __oflag, __builtin_va_arg_pack ());
}
extern int close(int fd);
static void
set_fortify_handler (void (*handler) (int sig))
{
  struct sigaction sa;
  sigaction (&sa);
  int fd = open ("/dev/null", 3);
  if (fd == -1)
    close (1);
}
extern void handler (int sig);
void
do_test (void)
{
  set_fortify_handler (handler);
}
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/219108/usr/bin/gcc -O2 -S
-fexceptions pr64465.c
pr64465.c: In function \u2018set_fortify_handler\u2019:
pr64465.c:34:1: error: BB 5 last statement has incorrectly set lp
 }
 ^
pr64465.c:34:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-mic-2 gcc-regression]$

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I get different ICE as attached. it is previously semi-latent bug exposed by
different inlining decisions.
/aux/hubicka/t.c: In function �do_test�:
/aux/hubicka/t.c:25:7: internal compiler error: in gimple_op_ptr, at
gimple.h:2276
   int fd = open ("/dev/null", 3);
       ^
0xdc53bf gimple_op_ptr
        ../../gcc/gimple.h:2276
0xdc5dc6 gimple_call_arg_ptr
        ../../gcc/gimple.h:2858
0xdcf898 copy_bb
        ../../gcc/tree-inline.c:1889
0xdd2416 copy_cfg_body
        ../../gcc/tree-inline.c:2710
0xdd2f22 copy_body
        ../../gcc/tree-inline.c:2947
0xdd72e6 expand_call_inline
        ../../gcc/tree-inline.c:4616
0xdd7a08 gimple_expand_calls_inline
        ../../gcc/tree-inline.c:4752
0xdd7fff optimize_inline_calls(tree_node*)
        ../../gcc/tree-inline.c:4893
0x16ace2c inline_transform(cgraph_node*)
        ../../gcc/ipa-inline-transform.c:507
0xc45c50 execute_one_ipa_transform_pass
        ../../gcc/passes.c:2176
0xc45db9 execute_all_ipa_transforms()
        ../../gcc/passes.c:2217
0x86c8d6 cgraph_node::expand()
        ../../gcc/cgraphunit.c:1791
0x86cf43 expand_all_functions
        ../../gcc/cgraphunit.c:1934
0x86da7c symbol_table::compile()
        ../../gcc/cgraphunit.c:2284
0x86dc2d symbol_table::finalize_compilation_unit()
        ../../gcc/cgraphunit.c:2361
0x6c751d c_write_global_declarations()
        ../../gcc/c/c-decl.c:10778
>From gcc-bugs-return-472028-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 01 20:30:17 2015
Return-Path: <gcc-bugs-return-472028-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17035 invoked by alias); 1 Jan 2015 20:30:16 -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 17013 invoked by uid 48); 1 Jan 2015 20:30:11 -0000
From: "maltsevm at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/64468] New: Incorrect indentation in Doxygen-generated sources of libstdc++
Date: Thu, 01 Jan 2015 20:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: maltsevm at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_file_loc bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-64468-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-01/txt/msg00022.txt.bz2
Content-length: 1091

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

            Bug ID: 64468
           Summary: Incorrect indentation in Doxygen-generated sources of
                    libstdc++
           Product: gcc
           Version: 5.0
               URL: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxyge
                    n/a00971_source.html
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: web
          Assignee: unassigned at gcc dot gnu.org
          Reporter: maltsevm at gmail dot com

See the attached URL. The indentation is broken (it is best visible near line
150 and further). The URL is given as an example, the problem affects other
sources and versions (at least, 4.9.2 and 4.6.4 are affected; previous versions
don't include libstd++ docs).

Probably the reason is incorrect configuration of Doxygen: libstdc++ sources
use tab size equal to 8 spaces, and in libstdc++-v3/doc/doxygen/user.cfg.in
this value is set to be equal to 4:
TAB_SIZE = 4

Some parts of the library are indented using only spaces, without tabs.

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |jakub at gcc dot gnu.org

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34379&action=edit
gcc5-pr64465.patch

Updated patch that works on this testcase.  From the cgraph.c comments, it
looks
like e.g. during function versioning we rely on fixup_cfg to fix it up, but
during inlining I think we need to do it immediately.  TODO_cleanup_cfg is on
during inlining.

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> ---
> Updated patch that works on this testcase.  From the cgraph.c comments, it
> looks
> like e.g. during function versioning we rely on fixup_cfg to fix it up, but
> during inlining I think we need to do it immediately.  TODO_cleanup_cfg is on
> during inlining.

execute_fixup_cfg is called from inline_transform, I wonder why it does not
catch
this case?  Anyway updating things immediately after redirection seems like
right
thing to do.  Any reason why this is not part of redirect_stmt_to_callee?

Thanks for looking into this (I am flying back to Calgary at Friday and should
be
back in regular schedule)

Honza

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #6)
> > Updated patch that works on this testcase.  From the cgraph.c comments, it
> > looks
> > like e.g. during function versioning we rely on fixup_cfg to fix it up, but
> > during inlining I think we need to do it immediately.  TODO_cleanup_cfg is on
> > during inlining.
> 
> execute_fixup_cfg is called from inline_transform, I wonder why it does not
> catch
> this case?  Anyway updating things immediately after redirection seems like
> right
> thing to do.  Any reason why this is not part of redirect_stmt_to_callee?

Because the early inliner does not call it.

And the reason why I haven't changed cgraph.c is:
      /* We need to defer cleaning EH info on the new statement to
         fixup-cfg.  We may not have dominator information at this point
         and thus would end up with unreachable blocks and have no way
         to communicate that we need to run CFG cleanup then.  */
comment, I initially had there the maybe_clean_or_replace_eh_stmt
(e->call_stmt, new_stmt); but that comment made me to reconsider.  Which is why
I've limited it in the patch to the inliner (id->call_stmt test), and don't do
this when versioning functions.

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
> > execute_fixup_cfg is called from inline_transform, I wonder why it does not
> > catch
> > this case?  Anyway updating things immediately after redirection seems like
> > right
> > thing to do.  Any reason why this is not part of redirect_stmt_to_callee?
> 
> Because the early inliner does not call it.

Early inliner should not do any redirection however.

> 
> And the reason why I haven't changed cgraph.c is:
>       /* We need to defer cleaning EH info on the new statement to
>          fixup-cfg.  We may not have dominator information at this point
>          and thus would end up with unreachable blocks and have no way
>          to communicate that we need to run CFG cleanup then.  */
> comment, I initially had there the maybe_clean_or_replace_eh_stmt
> (e->call_stmt, new_stmt); but that comment made me to reconsider.  Which is why
> I've limited it in the patch to the inliner (id->call_stmt test), and don't do
> this when versioning functions.

Hmm, OK, it seems like someone (me?) already tried this :)

However I do not see why function versioning should be any safer than inliner
use in
this respect.

Honza

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I believe with function versioning you create a new function and fixup_cfg pass
is what will be run first on that, isn't that the case?  In any case, there is
no guarantee TODO_cleanup_cfg will be executed right after function versioning,
so the changes should be postponed till it will be ensured.

The inliner on the other side always uses TODO_cleanup_cfg and thus should be
safe.

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Jan  5 21:45:08 2015
New Revision: 219200

URL: https://gcc.gnu.org/viewcvs?rev=219200&root=gcc&view=rev
Log:
    PR tree-optimization/64465
    * tree-inline.c (redirect_all_calls): During inlining
    clean up EH stmts and EH edges if redirect_call_stmt_to_callee
    changed the stmt to a non-throwing call.

    * gcc.dg/pr64465.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr64465.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-inline.c

[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|jakub at gcc dot gnu.org           |
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.