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()
>
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
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
Hi Michal and Mark,
> > GNU Guile 2.2.5 build fails because accept4 detection on OpenIndiana
> > 2019.04 (illumos distribution) [1] fails due to "-lsocket -lnsl" not
> > being part of the linking process and the build system then tries to
> > build it's vendored accept4:
>
> I believe this is an
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
Florian Weimer wrote:
> > In the NEWS entry, Florian writes:
> >
> >Applications which use the
> >copy_file_range function will have to be run on kernels which implement
> >the copy_file_range system call.
> >
> > I find this misleading. Coreutils will want to continue to use
> >
Hi Michal,
Michal Nowak writes:
> GNU Guile 2.2.5 build fails because accept4 detection on OpenIndiana
> 2019.04 (illumos distribution) [1] fails due to "-lsocket -lnsl" not
> being part of the linking process and the build system then tries to
> build it's vendored accept4:
I believe this is
> 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
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
* Bruno Haible:
> Pádraig Brady wrote:
>> https://sourceware.org/ml/libc-alpha/2019-06/msg00873.html
>
> In the NEWS entry, Florian writes:
>
>Applications which use the
>copy_file_range function will have to be run on kernels which implement
>the copy_file_range system call.
>
> I
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);
Pádraig Brady wrote:
> https://sourceware.org/ml/libc-alpha/2019-06/msg00873.html
In the NEWS entry, Florian writes:
Applications which use the
copy_file_range function will have to be run on kernels which implement
the copy_file_range system call.
I find this misleading. Coreutils
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
On 07/06/19 09:04, Paul Eggert wrote:
> Although I agree with both of Bruno's reasons, on further thought it makes
> sense
> for Gnulib to provide a stub instead of an emulation for this particular
> function.
>
> The primary use for copy_file_range is to copy files more efficiently than a
>
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
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
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.
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)
{
...
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
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 :
20 matches
Mail list logo
