search for: nothrow

We want to modify the aforementioned check so that it does not flag the exceptions that aren't nothrow copy constructible/assignable. This page http://clang.llvm.org/extra/clang-tidy/#using-clang-tidy tells me to dump the configs of all the checks using %clang-tidy -checks=* -dump-config but it does not mention the cert-err60-cpp. How do I modify the configuration of this check so that it ignore...

...ption, and so the checks of its result against nullptr were correct... > right? > > Turns out I'm probably wrong. At least according to this stack overflow > post. But then, what is the correct way to use operator new when compiling > with -fno-exceptions? Do we need to add (std::nothrow) to all uses of `new`? I think this should be added by Clang itself. Or we need to use STL compiled with -fno-exceptions (libstdc++ or libc++). > Best, > Jonas Eugene.

> I think we can do such optimization with operator new, because new never returns null. This is incorrect in the case of `new (std::nothrow) ...` - the whole point of `(std::nothrow)` is to tell new that it should return NULL in case of failure, rather than throw an exception (bad_alloc). But the point here is not the actual return value, but the fact that the compiler misses that the constructor has side-effects. -- Mats On 31 Ma...

...s by not linking std library, so we must assume malloc/free always have side-effect like other common functions, unless we know we will link std library only at link-time. Thanks, -Jiangning 2015-03-31 17:51 GMT+08:00 Kevin Qin <kevinqindev at gmail.com>: > Yes, I classified `new (std::nothrow)` to be a malloc like allocation. See > the next sentence. > > > 2015-03-31 17:48 GMT+08:00 mats petersson <mats at planetcatfish.com>: > >> > I think we can do such optimization with operator new, because new >> never returns null. >> >> This is inco...

...; If programmers want to do this, they need to compile their program with > -ffreestanding. > > >> >> Thanks, >> -Jiangning >> >> >> 2015-03-31 17:51 GMT+08:00 Kevin Qin <kevinqindev at gmail.com>: >> >>> Yes, I classified `new (std::nothrow)` to be a malloc like allocation. >>> See the next sentence. >>> >>> >>> 2015-03-31 17:48 GMT+08:00 mats petersson <mats at planetcatfish.com>: >>> >>>> > I think we can do such optimization with operator new, because new >>&gt...

...Nov 2, 2016 at 9:41 AM, Jonas Wagner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > I think this should be added by Clang itself. > > > I don't think so. There are several sources online that indicate that > developers need to *manually* specify std::nothrow. If they don't, > operator new will throw an exception even if code is compiled with > -fno-exception. This will abort the program. > That's correct. The default new should never return nullptr, even with -fno-exceptions. It should either succeed, throw an exception, or abort. At...

...nce/cstdlib/malloc/, malloc may return null if this memory allocation fails. So why we assume malloc() always returns a non-null pointer here? I think we can do such optimization with operator new, because new never returns null. But for all malloc like allocation(malloc, calloc, and new with std::nothrow), we shouldn't do this. That regression test exists for a long time, I'm not sure if there's any special reason. Does anybody know about this? -- Thanks, Kevin Qin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llv...

On Jul 28, 2011, at 8:41 AM, Peter Lawrence wrote: > In short the problem is that there is an ambiguity between a cleanup handler having > an Action Table entry that looks like > .byte 1 ;; Type = 1 (ie #1 entry in Types Table) > .byte 0 ;; Next = 0 (ie none, ie this is the list terminator for this try-statement) > together with a corresponding Types Table entry #1 that looks

...h three EH types: 1. No tables (SjLj) 2. Dwarf tables (DwarfCFI) 3. Specific EH tables (ARM, Win64?) ** Debug & Profiling ** In debug/profile mode (-g, -pg), none of the optimizations that prune unwind information should be allowed to run. I believe currently this is informed via the uwtable/nothrow function attributes, but since their use is controversial, we can reach situations where information is indeed removed when it shouldn't happen. (see Logan's post). ** Function Attributes Proposal ** I still don't have a clear idea on what do we need, but being overly conservative, we...

...t; memory or other system resource, that may change between two consecutive > calls (such as feof in a multithreading environment)." > > In particular, pure/const imply termination - something that's not entirely > clear w.r.t readonly. However, apparently, they don't imply nothrow. I've > actually always thought they *do* imply it - and said so on-list :-) - but > it looks like GCC itself doesn't interpret them that way. E.g. see John > Regher's example here: https://t.co/REzy5m1tT3 > So there's at least one use-case for possibly throwing readonly...

...wrote: > > Thanks for the reply. > >> Sorry, yes. No difference between explicit error handling and >> exceptions. The difference is in all the functions that don't have >> explicit error handling but (in the exception-using equivalent code) >> aren't marked nothrow (where, without exceptions, the compiler could >> move the increment across the call). > > According to your argument, assuming that correctly annotating throw specifications is impractical, if one wants to mitigate the performance implications of exceptions, not using exceptions onesel...

...n failures and that it is impractical to maintain such information in a large codebase), which is the main cause that code using exceptions cannot be optimized as effectively as code that does not. That (lack of precise throw information for external functions due to requiring manual annotation of nothrow), I believe, is a significant issue, yes. >> The ABI - the agreement between compilation of different files/objects >> limits what the compiler can do to change the mechanism for exception >> handling. The compiler building 'f()' and the compiler building f()'s >&g...

On Jul 27, 2011, at 11:10 AM, John McCall wrote: > >> 4) IIUC, llvm has inherited a bug from gcc where the debugger >> cannot let the user know an exception is >> going to be uncaught until after the stack has been unwound -- >> contrary to the design intentions of the >> unwind library that most exception implementations are based on >> (with a two

...u guys don't want to change it. It may never be a problem with gcc. This is the definition of pthread_mutex_lock() in glibc. There aren't any magic hints that this invalidates memory: extern int pthread_mutex_lock (pthread_mutex_t *__mutex) __THROWNL __nonnull ((1)); THOWNL is attribute((nothrow)). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150225/1d46e029/attachment.html>

...absolutely identical, as are the indexes used to reference the Action Table from the region maps. -Peter Lawrence. ------------------------------------------------------------------------ --------------------------------------- extern void foo(); extern void print(const char *) __attribute__((nothrow)); void bar () { try { foo(); } catch (...) { print("caught (...)\n"); } } .section __TEXT,__gcc_except_tab ... ;; CallSite Table .long Ltmp0-Leh_func_begin0 .long Ltmp1-Ltmp0...

...ut evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs. never-exceptional cases. 1. C vs. C++ We have two unwind flags: nounwind, which flags functions that can't unwind (leaf, nothrow, etc) and uwtable, which forces generation of the table regardless of nounwind. It seems sensible that C++ code with exceptions enabled should generate the tables for all functions, in case they're called by (or call) external functions. In C we don't want any of that. GCC seems to never e...

...9;re seeing the results from it. > > The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional > vs. never-exceptional cases. > > > 1. C vs. C++ > > We have two unwind flags: nounwind, which flags functions that can't unwind (leaf, > nothrow, etc) and uwtable, which forces generation of the table regardless of > nounwind. It seems sensible that C++ code with exceptions enabled should generate > the tables for all functions, in case they're called by (or call) external functions. > In C we don't want any of that. > &...

Hi! Company behind PVS-Studio analyzed relatively recent version of LLVM and some results are reported in http://www.viva64.com/en/b/0446/. Eugene.

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t

I recall it was things we could deduce by scanning the method before we optimized it, eg deduced noreturn/nothrow. I'd have to go check to be sure. Once you allow inlining, you're pretty much telling your users they had better give you compatible definitions. We wanted to make sure that if users gave us compatible defs (mainly: same source, but optimized in one CU and not in another), we wouldn'...