Created attachment 31995 [details] Testcase This is a fallout of the fix for PR tree-opt/59920: the attached testcase passes at -0O but fails at -O1 (and interestingly passes at -O2) on x86-64/Linux. This is apparently related to inlining, see the comment in the testcase. Severity is "major" because this breaks the SJLJ exception scheme in Ada, which has been rock-solid for about a decade.
Thanks for the report, will have a look tomorrow.
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. 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. 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)?
Created attachment 31997 [details] gcc49-pr60003-1.patch Untested quick hack to set cfun->has_nonlocal_label, seems to work on this testcase.
> 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.
Created attachment 31998 [details] gcc49-pr60003-2.patch Untested variant which makes __builtin_setjmp_receiver a returns twice function. For some strange reason this doesn't work, the test hangs.
Created attachment 31999 [details] gcc49-pr60003-3.patch Untested third variant, which just makes sure cfun->calls_setjmp is set even for __builtin_setjmp_receiver. This one seems to work for the testcase.
(In reply to Eric Botcazou from comment #4) > > 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. Ok, so you prefer the first patch? Now to write some comment explaining why... > > 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. At GIMPLE level indeed, cfun->calls_setjmp is now purely about whether the abnormal edges are constructed or not, the tree-tailcall.c use probably could go. For normal setjmp calls (and fork etc.) we do nothing though at the RTL level though, so cfun->calls_setjmp is probably still needed there.
> Ok, so you prefer the first patch? Now to write some comment explaining > why... Yes, I'm very fond of one-liners. :-) You can say that the label taken by __builtin_setjmp is treated as a non-local label by the middle-end.
Created attachment 32000 [details] gcc49-pr60003.patch Ok, so this is what I'm going to bootstrap/regtest.
Author: jakub Date: Sat Feb 1 08:40:31 2014 New Revision: 207382 URL: http://gcc.gnu.org/viewcvs?rev=207382&root=gcc&view=rev Log: PR tree-optimization/60003 * gimple-low.c (lower_builtin_setjmp): Set cfun->has_nonlocal_label. * profile.c (branch_prob): Use gimple_call_builtin_p to check for BUILT_IN_SETJMP_RECEIVER. * tree-inline.c (copy_bb): Call notice_special_calls. * gcc.c-torture/execute/pr60003.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr60003.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-low.c trunk/gcc/profile.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
Fixed.
*** Bug 60006 has been marked as a duplicate of this bug. ***