GNU bug report logs - #36370
27.0.50; XFIXNAT called on negative numbers

Previous Next

Full log

Message #45 received at 36370 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 36370 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org
Subject: Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers
Date: Fri, 28 Jun 2019 11:06:15 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.