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.
