[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining

["ebotcazou at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Ah, I see what's going on.  eliminate_unnecessary_calls in dce calls
> clear_special_calls.  Before my patch, __builtin_setjmp lowering would add a
> dummy non-local label to the function, so that while dce would clear
> cfun->calls_setjmp, cfun->has_nonlocal_label would be still set, but with my
> patch that is no longer happening, so stmt_can_make_abnormal_goto is always
> false during inlining and the corresponding edges aren't added.

OK, thanks for analysis.

> So, either e.g. tree-cfg.c could just set cfun->has_nonlocal_label when it
> sees a __builtin_setjmp_receiver (or say gimple-low.c when lowering
> __builtin_setjmp could set it) to restore status quo.

At the RTL level, cfun->has_nonlocal_label is set when __builtin_setjmp_setup
is expanded (in expand_builtin_setjmp_setup) so I think that we should do the
same at the Tree level.  My preference would be for gimple-low.c but no strong
opinion.

> Or I wonder, is there any special reason to avoid cfun->calls_setjmp when
> you actually call setjmp?  Like say make __builtin_setjmp_receiver
> ECF_RETURNS_TWICE, or just special casing it in notice_special_calls and in
> the inliner (which just should call notice_special_calls)?

Historically cfun->calls_setjmp is a big hammer that disables optimization
passes, which was unnecessary for __builtin_setjmp because everything is
exposed in the IL.  Nowadays the distinction with the regular setjmp is less
clear, but I think that we should lean towards clearing cfun->calls_setjmp
rather than setting it, or else reducing its impact on optimization passes.