On Thu, Jun 27, 2019 at 11:45 PM Bruno Haible <br...@clisp.org> wrote: > Can you please show an example code on which the change makes a difference?
int main(void) { eassume (printf("hi\n")); return 0; } Or, more realistically: extern int potentially_inlined_function(int i); int main(void) { ... eassume(potentially_inlined_function(i)); return i >= 0; } With the old gnulib eassume, the programmer has to know whether potentially_inlined_function is inlined (in which case the eassume appears to be treated as a nop) or not (in which case a potentially expensive external function call is generated). With the new eassume, these cases are distinguished by the compiler. This makes it safe to use function expressions in eassume, whether the function is inlined or not. (That GCC doesn't actually do very much with this information is a separate issue). This approach does fail for certain compound expressions passed as arguments to eassume: eassume(i >= 0 && i < complicated_function ()); will not "split" the && expression, so it'll behave differently from eassume(i >= 0); eassume(i < complicated_function ()); But even in those cases, this approach is better than the old approach of actually evaluating complicated_function. At first, I thought it would be better to have a __builtin_assume expression at the GCC level, but even that would have to have "either evaluate the entire condition expression, or evaluate none of it" semantics. We'll just have to get used to splitting our eassumes, I think.