[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-23
                 CC|                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
-g isn't needed to reproduce this.  Started with r198096, the huge function
with ~ 5000 or how many basic blocks has over 200 setjmp calls in it, so
starting with the r198096 commit we create probably about 1000 or so more basic
blocks, hundreds of thousands abnormal edges (but still *.cfg dump is emitted
quickly), I think all the memory is eaten by huge PHI argument lists.

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is it valid to longjmp to a setjmp where the containing function hasn't
terminated yet, but the scope in which the setjmp has been declared has been
left already?
I mean:
  { if (setjmp (jmp_buf) == 0) bar (); }
  baz ();
and only baz () doing the longjmp?  I see the standard talks about leaving the
caller, or about VLAs, and for C++ about destructors (but e.g. doesn't talk
about crossing constructors).
What about:
  { volatile int a; if (setjmp (jmp_buf) == 0) bar (&a, 0); else bar (&a, 1); }
  { volatile int b; baz (&b); }
and baz doing longjmp?  This is effectively entering a scope that has been left
already, we could very well share the stack slot between a and b etc.
And for C++, say
struct A { A (); ~A (); };
...
  { volatile A a; if (setjmp (jmp_buf) == 0) bar (&a, 0); else bar (&a, 1); }
  baz (&b);
?  Supposedly there are no destructors that would make this invalid, on the
other side I think the C++ wording is as if setjmp was catch and longjmp throw,
and you really can't do that with throw/catch.

Anyway, the idea was that if longjmp to setjmp that has already left it's scope
was invalid, we could do some hacks and add the EDGE_ABNORMAL edges only from
calls within the scope of the setjmp.  As the testcase has all the setjmp
surrounded by small scopes that have only one _setjmp together with at most a
couple of calls, this would dramatically reduce the number of EH edges,
SSA_NAMEs etc.

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[carlos at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Jakub Jelinek from comment #2)
> Is it valid to longjmp to a setjmp where the containing function hasn't
> terminated yet, but the scope in which the setjmp has been declared has been
> left already?

IMO this is undefined behaviour.

I can't convince myself that can be anything but that.

However, as written ISO C allows this, but it's allowance would require that
the entire state of the scope should be kept around for the duration of the
function just to satisfy the wording of setjmp/longjmp in the standard. I can't
justify that to myself.

An implementation might detect a setjmp in the scope, along with volatile or
non-automatic variables and then making sure the state of the scope is never
reused so a longjmp can return to it.

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
For C I believe it's valid to jump back into a scope like that.  I don't 
think it affects reuse of stack space, because the variables in the scope 
that was left have no defined values at longjmp time and so have no 
defined values on the second return from setjmp.

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> -g isn't needed to reproduce this.  Started with r198096, the huge function
> with ~ 5000 or how many basic blocks has over 200 setjmp calls in it, so
> starting with the r198096 commit we create probably about 1000 or so more
> basic blocks, hundreds of thousands abnormal edges (but still *.cfg dump is
> emitted quickly), I think all the memory is eaten by huge PHI argument lists.

It's precisely for this kind of situation that the "weirdo" (your word IIRC :-)
lowering of __builtin_setjmp was added.  Maybe something similar could be done.

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #5)
> > -g isn't needed to reproduce this.  Started with r198096, the huge function
> > with ~ 5000 or how many basic blocks has over 200 setjmp calls in it, so
> > starting with the r198096 commit we create probably about 1000 or so more
> > basic blocks, hundreds of thousands abnormal edges (but still *.cfg dump is
> > emitted quickly), I think all the memory is eaten by huge PHI argument lists.
> 
> It's precisely for this kind of situation that the "weirdo" (your word IIRC
> :-) lowering of __builtin_setjmp was added.  Maybe something similar could
> be done.

So perhaps a dummy internal call inserted right before the setjmp/returns_twice
call and a dummy setjmp/returns_twice dispatcher and just add the AB edges?
The internal call before the setjmp/returns_twice calls would have FALLTHRU
edge to the setjmp/returns_twice call and AB edge to the dummy dispatcher and
the dummy dispatcher would have AB edge to all the setjmp/returns_twice calls.
Guess that would be enough for GIMPLE purposes, the question is what we want at
RTL level.

I've tried the #c0 testcase with _setjmp calls replaced with __builtin_setjmp,
and while it also isn't really small IL, e.g. the __builtin_setjmp_dispatcher
bb has 294 PHIs, each with 1852 args, and then each of the
__builtin_setjmp_receiver blocks has those 294 PHIs with 2 args, it is far
better than if we have
over 200 basic blocks for _setjmp calls, each with 294 PHIs and each with 1852
arguments.  That is still 100mil. PHI arguments right now vs. 600000 PHI
arguments after the change.

[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31963
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31963&action=edit
gcc49-pr59920.patch

Ok, started hacking on this.  I think I have the tree-cfg.c side of the thing
pretty much ready (appart from removing make_abnormal_goto_edges), including
being friendly to OpenMP and even using the OpenMP restrictions to get smaller
AB edge coverage, but things to do still include:
1) tree-inline.c
2) expansion (ensure the right edges exists after expansion)
3) see how it will play together with __builtin_setjmp, hopefully just kill
   __builtin_setjmp_dispatcher altogether

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31964
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31964&action=edit
gcc49-pr59920.patch

Updated patch.  Apparently we were dropping the abnormal edges during expansion
anyway, so there is nothing to do for RTL right now.  The patch results in some
Ada miscompares though, will debug tomorrow.

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, the plan is not essentially remove the __builtin_setjmp_dispatcher, but
just replace it with the internal function (ABNORMAL_DISPATCHER).
Some further observations - tree-cfg.c factors out computed gotos (but
apparently regardless of OpenMP regions, so I bet it is easy to construct
OpenMP + computed goto testcases that will ICE), so there is no need to insert
ABNORMAL_DISPATCHER for computed gotos, the edges can go directly, which will
hopefully fix a couple of computed goto related ICEs where
find_taken_edge_computed_goto ICEd because it wasn't expecting to see the extra
hop.  And, for inlining also we want to ignore computed gotos, they can't
transfer control to the caller's forced labels, no matter of inlined or not.

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31964|0                           |1
        is obsolete|                            |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31966
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31966&action=edit
gcc49-pr59920.patch

Updated patch I'm going to bootstrap/regtest now.

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Jan 29 11:02:46 2014
New Revision: 207231

URL: http://gcc.gnu.org/viewcvs?rev=207231&root=gcc&view=rev
Log:
    PR middle-end/59917
    PR tree-optimization/59920
    * tree.c (build_common_builtin_nodes): Remove
    __builtin_setjmp_dispatcher initialization.
    * omp-low.h (make_gimple_omp_edges): Add a new int * argument.
    * profile.c (branch_prob): Use gsi_start_nondebug_after_labels_bb
    instead of gsi_after_labels + manually skipping debug stmts.
    Don't ignore bbs with BUILT_IN_SETJMP_DISPATCHER, instead
    ignore bbs with IFN_ABNORMAL_DISPATCHER.
    * tree-inline.c (copy_edges_for_bb): Remove
    can_make_abnormal_goto argument, instead add abnormal_goto_dest
    argument.  Ignore computed_goto_p stmts.  Don't call
    make_abnormal_goto_edges.  If a call might need abnormal edges
    for non-local gotos, see if it already has an edge to
    IFN_ABNORMAL_DISPATCHER or if it is IFN_ABNORMAL_DISPATCHER
    with true argument, don't do anything then, otherwise add
    EDGE_ABNORMAL from the call's bb to abnormal_goto_dest.
    (copy_cfg_body): Compute abnormal_goto_dest, adjust copy_edges_for_bb
    caller.
    * gimple-low.c (struct lower_data): Remove calls_builtin_setjmp.
    (lower_function_body): Don't emit __builtin_setjmp_dispatcher.
    (lower_stmt): Don't set data->calls_builtin_setjmp.
    (lower_builtin_setjmp): Adjust comment.
    * builtins.def (BUILT_IN_SETJMP_DISPATCHER): Remove.
    * tree-cfg.c (found_computed_goto): Remove.
    (factor_computed_gotos): Remove.
    (make_goto_expr_edges): Return bool, true for computed gotos.
    Don't call make_abnormal_goto_edges.
    (build_gimple_cfg): Don't set found_computed_goto, don't call
    factor_computed_gotos.
    (computed_goto_p): No longer static.
    (make_blocks): Don't set found_computed_goto.
    (get_abnormal_succ_dispatcher, handle_abnormal_edges): New functions.
    (make_edges): If make_goto_expr_edges returns true, push bb
    into ab_edge_goto vector, for stmt_can_make_abnormal_goto calls
    instead of calling make_abnormal_goto_edges push bb into ab_edge_call
    vector.  Record mapping between bbs and OpenMP regions if there
    are any, adjust make_gimple_omp_edges caller.  Call
    handle_abnormal_edges.
    (make_abnormal_goto_edges): Remove.
    * tree-cfg.h (make_abnormal_goto_edges): Remove.
    (computed_goto_p, get_abnormal_succ_dispatcher): New prototypes.
    * internal-fn.c (expand_ABNORMAL_DISPATCHER): New function.
    * builtins.c (expand_builtin): Don't handle
    BUILT_IN_SETJMP_DISPATCHER.
    * internal-fn.def (ABNORMAL_DISPATCHER): New.
    * omp-low.c (make_gimple_omp_edges): Add region_idx argument, when
    filling *region also set *region_idx to (*region)->entry->index.

    * gcc.dg/pr59920-1.c: New test.
    * gcc.dg/pr59920-2.c: New test.
    * gcc.dg/pr59920-3.c: New test.
    * c-c++-common/gomp/pr59917-1.c: New test.
    * c-c++-common/gomp/pr59917-2.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/gomp/pr59917-1.c
    trunk/gcc/testsuite/c-c++-common/gomp/pr59917-2.c
    trunk/gcc/testsuite/gcc.dg/pr59920-1.c
    trunk/gcc/testsuite/gcc.dg/pr59920-2.c
    trunk/gcc/testsuite/gcc.dg/pr59920-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/builtins.def
    trunk/gcc/gimple-low.c
    trunk/gcc/internal-fn.c
    trunk/gcc/internal-fn.def
    trunk/gcc/omp-low.c
    trunk/gcc/omp-low.h
    trunk/gcc/profile.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-cfg.c
    trunk/gcc/tree-cfg.h
    trunk/gcc/tree-inline.c
    trunk/gcc/tree.c

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

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

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Nice work, it successfully passed our regression tests with the SJLJ exception
scheme, which is piggybacked on __builtin_setjmp/__builtin_longjmp in Ada.

[Bug tree-optimization/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Nice work, it successfully passed our regression tests with the SJLJ
> exception scheme, which is piggybacked on __builtin_setjmp/__builtin_longjmp
> in Ada.

Pilot error, it breaks the SJLJ exception scheme when inlining is enabled, I'll
try to come up with a C testcase.