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

Bruno Haible wrote: I like this wording. OK, I merged that into the wording I proposed and installed the attached. One new point that I added is that I sometimes use 'assume (X)' to pacify GCC so that it does not issue a bogus warning in nearby code; this benefit of 'assume' is independent

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

[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I agree. There's a limitation bad enough for me to consider it a bug > in curre

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

Pip Cet wrote: > My suggestion would be "Assume that R always holds. This lets the > compiler optimize accordingly. Behavior is undefined if R is false, > fails to evaluate, or has side effects. Performance will suffer if R > contains function calls that are not inlined at compile time." I like

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

On Sat, Jun 29, 2019 at 10:31 AM Bruno Haible wrote: > Pip Cet wrote: > > I would like to state that the current assume does > > behave very badly when combined with -fno-inline-small-functions > > -fno-inline. > > Since we can't address this limitation through an acceptable change > to the 'assum

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

On Sat, Jun 29, 2019 at 5:31 PM Paul Eggert wrote: > >> This is not a valid use of 'assume'. It's documented that assume's argument > >> should be free of side effects. > > > > But the compiler makes no such assumption > > Sure, but if the caller uses 'assume' contrary to its documentation, that's

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

Hi Paul, > > + If you want the use of this macro to improve, not deteriorate, > > + performance, R should not contain function calls except to functions > > + that are declared 'inline __attribute__((__always_inline__))'. */ > > A reader of that might incorrectly conclude that using such f

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

Pip Cet wrote: This is not a valid use of 'assume'. It's documented that assume's argument should be free of side effects. But the compiler makes no such assumption Sure, but if the caller uses 'assume' contrary to its documentation, that's a problem with the caller's code, not with 'assume

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

Bruno Haible wrote: + If you want the use of this macro to improve, not deteriorate, + performance, R should not contain function calls except to functions + that are declared 'inline __attribute__((__always_inline__))'. */ A reader of that might incorrectly conclude that using such fun

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

Pip Cet wrote: > I would like to state that the current assume does > behave very badly when combined with -fno-inline-small-functions > -fno-inline. Since we can't address this limitation through an acceptable change to the 'assume' macro, we need to address it through documentation. > marking i

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

On Sat, Jun 29, 2019 at 5:41 AM Paul Eggert wrote: > Pip Cet wrote: > >eassume (global == 0); > >eassume (f ()); > > #else > >eassume (global == 0 && f ()); > > ... > > extern int global; > > > > int f(void) > > { > >return ++global; > > } > > > This is not a valid use of 'assume'.

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

On Fri, Jun 28, 2019 at 11:30 PM Bruno Haible wrote: > Pip Cet wrote: > > have started believing the "an inline function is as fast as a macro" > > mantra*, assuming you include inline functions with "function calls". > > Ah, that's where the entire topic with the function calls inside assume() >

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

Pip Cet wrote: eassume (global == 0); eassume (f ()); #else eassume (global == 0 && f ()); ... extern int global; int f(void) { return ++global; } This is not a valid use of 'assume'. It's documented that assume's argument should be free of side effects. It would be nice if 'as

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

Bruno Haible wrote: I think we should change the documentation of 'assume' to say that when it invokes functions, these functions should be marked '__attribute__ ((__always_inline__))', otherwise performance will be worse than without the 'assume', not better. I suggest something simpler and a

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

Pip Cet wrote: > have started believing the "an inline function is as fast as a macro" > mantra*, assuming you include inline functions with "function calls". Ah, that's where the entire topic with the function calls inside assume() comes from! I agree it's an important case (more important than t

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

> OptionsResult > none increment > -DASSUME_GNULIBincrement > -DTWO_ASSUMES single-store > -DASSUME_GNULIB -DTWO_ASSUMES increment Thanks, I should have included that. However, please note that in the -DA

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

On Fri, Jun 28, 2019 at 7:11 PM Bruno Haible wrote: > Pip Cet wrote: > > 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? > > I reproduce this with GCC versions 5.4.0, 6.5.0, 7.4.0, 8.3.0, and

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

On Freitag, 28. Juni 2019 19:15:06 CEST Pip Cet wrote: > On Fri, Jun 28, 2019 at 5:46 PM Paul Eggert wrote: > > Pip Cet wrote: > > > It's way too easy > > > to do something like > > > > > > eassume(ptr->field >= 0 && f(ptr)); > > > > > > when what you mean is > > > > > > eassume(ptr->field >= 0);

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

On Fri, Jun 28, 2019 at 5:46 PM Paul Eggert wrote: > Pip Cet wrote: > > 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)); > > These mean the same thing. I'm really convinced t

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

Pip Cet wrote: > 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? I reproduce this with GCC versions 5.4.0, 6.5.0, 7.4.0, 8.3.0, and 9.1.0. 1. Take the files foo.c and bar.c from

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

Pip Cet wrote: 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)); These mean the same thing. Both tell the compiler that a certain condition (A && B) is known to be true, and that behavior is undefined

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

On Fri, Jun 28, 2019 at 12:14 PM Bruno Haible 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.

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

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

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

Pip Cet wrote: > Or, more realistically: > > extern int potentially_inlined_function(int i); > > int main(void) > { > ... > eassume(potentially_inlined_function(i)); > return i >= 0; > } OK, I see... > This makes it safe to use function expressions in eassume, whether the > function is in

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

Oops, the test case that I meant to show is this one: foo.c = #include #define assume(R) ((R) ? (void) 0 : __builtin_unreachable ()) //#define assume(R) (!__builtin_constant_p (!(R) == !(R)) || (R) ? (void) 0 : __builtin_unreachab

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

On Thu, Jun 27, 2019 at 9:13 PM Paul Eggert wrote: > On 6/27/19 12:56 PM, Pip Cet wrote: > > The eassume tells GCC i is nonnegative, since (!(i >= 0) == !(i >= 0)) > > is indeed a constant. > > Ah! Thanks, I didn't catch that subtle point. Would the attached patch > to verify.h address that proble

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

On 6/27/19 4:45 PM, Bruno Haible wrote: Can you please show an example code on which the change makes a difference? Not easily, I'm afraid. I grabbed the latest Emacs master , ran './configure; make CFLAGS=-O2', edited the emacs lib/verify.h, and ra

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

Hi Paul, > I'll CC: this to bug-gnulib since it's a Gnulib issue. I have not > installed this patch into Gnulib on savannah. Can you please show an example code on which the change makes a difference? I used this test program foo.c =

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

On 6/27/19 12:56 PM, Pip Cet wrote: The eassume tells GCC i is nonnegative, since (!(i >= 0) == !(i >= 0)) is indeed a constant. Ah! Thanks, I didn't catch that subtle point. Would the attached patch to verify.h address that problem? This patch is for Gnulib, but would propagate into Emacs.