On 9 May 2018 at 09:59, Marc Glisse wrote: > On Wed, 9 May 2018, Jonathan Wakely wrote: > >> On 4 May 2018 at 15:20, Florian Weimer wrote: >>> >>> * John Carter: >>> >>>> But compile with ... >>>> gcc -O3 -W -Wall -Wextra -o a a.c >>>> ...now results in NO warnings! >>>> >>>> ie. Although gcc _knows_ the assert _will_ trigger at run time... it >>>> can't >>>> tell me at compile time anymore. >>>> >>>> ie. Counter intuitively, adding asserts and error checks to my code has >>>> made me less safe. >>> >>> >>> In glibc, we could warn if the assert expression is constant and >>> false. But I'm worried that this will produce lots and lots of false >>> positives after inlining, loop unrolling, and other optimizations. >>> >>> Has anyone tried something like this? >> >> >> I've been experimenting with something like that for assertions inside >> libstdc++. I want assertions that meet these properties: >> >> - enforced at compile time in constexpr evaluation (i.e. produce a >> compile-time error, not a runtime call to abort) >> >> - otherwise, issue a compile-time warning if the arguments are >> constant (using __builtin_constant_p) > > > This part doesn't work so well, especially with optimizations that duplicate > code (clone function, thread path, etc). You would need enough optimization > to see that the arguments are constant, but little enough that it still > looks like the user's code, and that's a hard compromize between > __builtin_constant_p and the new __builtin_early_constant_p. Yes, but luckily giving a warning here would just be QoI. The other two bullets are the hard requirements for libstdc++'s purposes (mandatory checking in constexpr that gives an error for failures, and optional run-time assertions). Warning about cases where the assertion would fail is nice to have, but not essential. > >> - otherwise, check at run-time. > > > -- > Marc Glisse
