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 ;)
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 -Floh. Am Dienstag, 18. Juli 2017 19:15:06 UTC+2 schrieb jj: > > Yeah, the test case Gaurav has is > > int main() > { > assert(!"gaurav"); > cout<<"hello\n"; > } > > which in debug builds concludes at compile time that the line with the > cout cannot be reached, hence there is no need to include libc++. The > current assert() implementation we have just does ((void)0) in NDEBUG > mode, so in that mode it must build cout in. I don't know standards > wise if an assert() implementation with __builtin_assume(x) should be > allowed, but to me that does sound like a valid implementation. The > assert() implementation does come from upstream musl however, so > perhaps we might want to fix there. > > 2017-07-18 19:44 GMT+03:00 Floh <[email protected] <javascript:>>: > > FYI, I'm seeing zero effect when playing around with these things in my > code > > base (with or without NDBUG, and the various assert macro > implementations. > > > > I'm surprised though that the small asm.js is just 57 KByte uncompressed > > despite using iostreams, when I tested iostream stuff in my code it was > > always around 400 KByte like the big test case, and this was caused by > all > > the iostream static initializers that were pulled in. Maybe something > causes > > the iostream init code to be stripped away? > > > > Cheers, > > -Floh. > > > > Am Dienstag, 18. Juli 2017 14:22:50 UTC+2 schrieb jj: > >> > >> Interesting test case. It looks like > >> > >> #ifdef NDEBUG > >> #define assert(x) (void)0 > >> #else > >> #define assert(x) ((void)((x) || (__assert_fail(#x, __FILE__, > >> __LINE__, __func__),0))) > >> #endif > >> > >> is to blame here. If I change that to: > >> > >> #ifdef NDEBUG > >> #define assert(x) (__builtin_assume((x))) > >> #else > >> #define assert(x) ((void)((x) || (__assert_fail(#x, __FILE__, > >> __LINE__, __func__),0))) > >> #endif > >> > >> then I get small output also with NDEBUG defined. Can you verify the > same? > >> > >> 2017-07-18 14:51 GMT+03:00 Gaurav Dewan <[email protected]>: > >> > Testcase here(all bcs, js makefile and gcc/clang generated exes): > >> > https://github.com/gauravdewan007/ndebug > >> > > >> > using -DNDEBUG helps to get rid of the assert (and save size and > prevent > >> > strings from getting into the code). > >> > Both clang and gcc generate smaller binary if -DNEDBUG option is > used. > >> > > >> > But using -DNDEBUG with emscripten build system causes a huge bloat > in > >> > size > >> > (irrespective of optimization level) and lot of new code is getting > >> > added > >> > > >> > -- > >> > 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] > <javascript:>. > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- 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.
