https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 12 Nov 2020, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711 > > --- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > > The issue with clearing nothrow is that those pesky builtins have > > that "sticky" while the per-stmt flag (gimple_call_nothrow ()) > > just amends it. Guess we might want to fix that (in gimple_call_flags) > > and then clear the flag always for -fnon-call-exceptions? > > > > I suppose all/most noexcept specifications in libstdc++ are similarly > > questionable. > > Let's not use too big a hammer though, -fnon-call-exceptions works fine for > languages (Ada, Go) that enable it by default and I'm quite wary of C++ folks > who try it once in a while, want to pessimize it because it doesn't work on > their questionable testcase, and then forget about it. > > Why not just extend what's done in build_common_builtin_nodes for > __builtin_alloca to the family of __builtin_mem* functions? Ah, didn't remember this place. Yes, I guess we could fix that place but that wouldn't conver the C/C++ frontends since those have the builtins already (wrongly) declared via the builtins.def machinery which does mark them NOTHROW (the __builtin_alloca handling also doesn't work for them). That means that similar to ATTR_MATHFN_FPROUNDING we'd need a variants of ATTR_NOTHROW_NONNULL_LEAF and some others that make the NOTHROW part conditional on flag_non_call_exceptions. Guess that's doable, double checking LTO behavior on merging of builtins from different CUs with possibly different settings of -fnon-call-exceptions needs to be done though.
