2017-07-18 20:36 GMT+03:00 Floh <[email protected]>: > Hmm I don't know, is this really fix-worthy? The behaviour is a bit > non-obvious, but in this case "the compiler is right" IMHO, and an assert > that resolves to false at compile-time isn't that useful in real-world code > either ;)
The idea would definitely not be to optimize unconditional "this is false at compile time", but it will allow compiler to optimize out branches and do other types of analysis. An image blitter might have an assert(stride % 16 ==0); in it, which, when one has run and tested in an asserts enabled build and is then doing NDEBUG for shipping, could turn into an optimized version of code later in the same function when compiler knows that some item will be aligned to 16 bytes. > > When I tested __builtin_assume(x) I got tons of warnings about "side effects > that will be discarded" as soon as there > was a function call in the assert (even for const/pure functions). It looks > like these functions must be manually annotated: > > https://stackoverflow.com/questions/38476278/discarded-side-effects-with-argument-passed-to-assert That could also help uncover real bugs, assert(foo) should certainly never have side effects for foo, though agreed that it might be difficult for compiler to know for sure, like the example on that page illustrates. I'll ask this as a question at musl mailing list. -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
