http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (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.
