Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Pip Cet]

On Thu, Jun 27, 2019 at 11:45 PM Bruno Haible <address@hidden> 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.