bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Pip Cet <pipcet@gmail.com>]

On Fri, Jun 28, 2019 at 12:14 PM Bruno Haible <bruno@clisp.org> wrote:
> Pip Cet wrote:
> > This makes it safe to use function expressions in eassume, whether the
> > function is inlined or not.
>
> By "safe" you mean that you want the function call to not be evaluated.

Sorry, sloppy wording there. You're right.

> You are mentioning a limitation:
>
> > eassume(i >= 0 && i < complicated_function ());
> >
> > will not "split" the && expression, so it'll behave differently from
> >
> > eassume(i >= 0);
> > eassume(i < complicated_function ());
>
> And I would mention a regression: When -flto is in use and the expression
> invokes an external potentially-inlined function, the old 'assume' would
> work fine, i.e. do optimizations across compilation-unit boundaries.

Sorry, can't reproduce that here. I'm sure the changes I need to make
are obvious once I've found them, but can you let me know your gcc
version?

> > But even in those cases, this approach is better than the old approach
> > of actually evaluating complicated_function.
>
> I disagree that it is better:

Sorry to be pedantic, but do you disagree that it is better in these
cases, or in general? The latter is a question that I'm trying to find
the answer to, but in these specific cases, it clearly is better.

(Just in the interest of full disclosure, I described the idea in a
different context; I think it's a neat hack, and I'm trying to figure
out whether it has practical applications, but if it doesn't then I
won't feel there's continuing disagreement).

>   1. The new 'assume' is worse when -flto is in use.

Maybe. Even if it is, though, that's a GCC limitation which I consider
likely to be fixable; your estimation of that may vary, of course.

>   2. You recommend to users to split assume(A && B) into assume(A); assume(B);
>      which is unnatural.

I make that recommendation independently of which assume is in use.

In practice, combining a complicated expression with a simple one in
an eassume is almost always not what you want to do. It's way too easy
to do something like

eassume(ptr->field >= 0 && f(ptr));

when what you mean is

eassume(ptr->field >= 0);
eassume(f(ptr));

(As an unusual special case, consider:

{
  printf("%d\n", i & 0x80000000);
  assume(i >= 0 && complicated_function());
}

which would generate different code from

{
  printf("%d\n", i & 0x80000000);
  assume(i >= 0);
  assume(complicated_function());
})

Combining two simple expressions and not getting the right result
appears, at this point, to run into a GCC limitation, but I'm not sure
where.

> > 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.
>
> No. At GCC level, it could have a "make the maximum of inferences - across
> all optimization phases -, but evaluate none of it" semantics.

There's no contradiction there: I'm saying that the programmer is
allowed to assume that the expression passed to assume either has been
evaluated, or hasn't been, with no in-between interpretations allowed
to the compiler. That means assume (A && B) isn't equivalent, in
general, to assume (A); assume (B); My suspicion is that the latter is
almost always what is intended.