Re: bison 3.7.1 failing to build due to autoconf cache

2020-08-02 Thread Bruno Haible
Hi Paul,

Paul Smith wrote:
> > If I compare the configure output from a run with using the cache
> > (fails) with one that doesn't use the cache (succeeds) the only
> > difference of interest is:
> 
>   -checking for sigprocmask... (cached) 1
>   +checking for sigprocmask... yes
>  ...
>   -checking for sigprocmask... (cached) 1
>   +checking for sigprocmask... yes

The situation with the Autoconf cache is not pretty: The documentation
merely states how the caching works, but
  - neither when and how the 'configure' user is meant to use it,
  - nor how an Autoconf macro should be written for good interoperation
with the cache.

More than 15 years ago, I heard "the autoconf cache is broken". As I
realized that the cache's contents depend on
  - the package you are compiling,
  - the version of a .m4 file with an autoconf macro,
  - the values of $CC and $CFLAGS (even '-m32' vs. '-m64'),
I stopped using it (except for collecting known values for cross-
compilation).

If you think that certain uses of the Autoconf cache can be made to
work reliably, please go ahead and document in the Autoconf manual
  - what these uses are,
  - what an Autoconf macro author should do for it to work.

Bruno




[PATCH] fcntl: document some F_SETLK errno variations

2020-08-02 Thread Paul Eggert
* doc/posix-functions/fcntl.texi (fcntl): Document
OpenIndiana, GNU/Linux, FreeBSD on NFS files.
---
 ChangeLog  | 6 ++
 doc/posix-functions/fcntl.texi | 8 
 2 files changed, 14 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index cec93905a..b078da4d3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2020-08-02  Paul Eggert  
+
+   fcntl: document some F_SETLK errno variations
+   * doc/posix-functions/fcntl.texi (fcntl): Document
+   OpenIndiana, GNU/Linux, FreeBSD on NFS files.
+
 2020-08-02  Bruno Haible  
 
oset: Add an 'iterator_atleast' operation.
diff --git a/doc/posix-functions/fcntl.texi b/doc/posix-functions/fcntl.texi
index 8696704ac..30500e83c 100644
--- a/doc/posix-functions/fcntl.texi
+++ b/doc/posix-functions/fcntl.texi
@@ -43,4 +43,12 @@ The replacement function does not support @code{F_SETFD},
 @code{F_GETFL}, @code{F_SETFL}, @code{F_GETOWN}, @code{F_SETOWN},
 @code{F_GETLK}, @code{F_SETLK}, and @code{F_SETLKW} on some platforms:
 mingw, MSVC 14.
+
+@item
+When a file does not support locking (such as on an NFS file system
+that does not support file locking), calls with @code{F_SETLK} and
+@code{F_SETLKW} fail with @code{errno} set to different values on
+different systems: @code{EINVAL} on OpenIndiana (as suggested by the
+POSIX 1003.1-2017 @code{fcntl} specification), @code{ENOLCK} on
+GNU/Linux, and @code{EOPNOTSUPP} on FreeBSD.
 @end itemize
-- 
2.25.4




Re: bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

2020-08-02 Thread Paul Smith
On Sun, 2020-08-02 at 18:58 -0400, Paul Smith wrote:
> If I compare the configure output from a run with using the cache
> (fails) with one that doesn't use the cache (succeeds) the only
> difference of interest is:
> 
>   @@ -378,7 +379,7 @@
>checking whether program_invocation_name is declared... yes
>checking whether program_invocation_short_name is declared... yes
>checking for raise... yes
>   -checking for sigprocmask... 1
>   +checking for sigprocmask... yes
>checking for readline... yes
>checking how to link with libreadline... -lreadline
>checking for readline/readline.h... yes
>   @@ -398,7 +399,7 @@
>checking for sighandler_t... yes
>checking for signbit macro... yes
>checking for signbit compiler built-ins... yes
>   -checking for sigprocmask... 1
>   +checking for sigprocmask... yes
>checking for stdint.h... yes
>checking for SIZE_MAX... yes
>checking for snprintf... yes

Sorry, this diff was from a cleaned-up version I was using for
comparison.  It obviously should be:

  -checking for sigprocmask... (cached) 1
  +checking for sigprocmask... yes
 ...
  -checking for sigprocmask... (cached) 1
  +checking for sigprocmask... yes





Re: bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

2020-08-02 Thread Paul Smith
On Sun, 2020-08-02 at 17:54 -0400, Paul Smith wrote:
> The latest Bison release 3.7.1 is not compiling for me, and it
> appears to be a gnulib issue.
> 
> Here's the failure:
> 
> gcc -DEXEEXT=\"\" -I. -I./lib -Ibison-3.7.1 -Ibison-3.7.1/lib \
>   -DDEFAULT_TEXT_DOMAIN=\"bison-gnulib\" -march=nehalem -mtune=intel \
>   -ffile-prefix-map=bison-3.7.1/= -O2 -fPIC -static-libgcc \
>   -MT lib/libbison_a-quotearg.o -MD -MP \
>   -MF lib/.deps/libbison_a-quotearg.Tpo -c -olib/libbison_a-quotearg.o \
>   `test -f 'lib/quotearg.c' || echo 'bison-3.7.1/'`lib/quotearg.c
> In file included from /usr/include/sys/param.h:28,
>  from bison-3.7.1/lib/minmax.h:34,
>  from bison-3.7.1/lib/quotearg.c:33:
> ./lib/signal.h:682:13: error: size of array 'verify_NSIG_constraint' is 
> negative
>   682 | typedef int verify_NSIG_constraint[NSIG <= 32 ? 1 : -1];
>   | ^~
> make[2]: *** [Makefile:5457: lib/libbison_a-quotearg.o] Error 1

Further investigation shows that the problem is that
HAVE_POSIX_SIGNALBLOCKING is set to 0 in the broken build.

It appears that the issue is related to some cached autoconf output
(yes, I know caching is not good and causes problems, but the
performance difference is so noticeable it's hard to ignore... and it
usually works).

If I check the autoconf cache I see that there are two variables to set
*_cv_func_sigprocmask: one is set to "yes" and one is set to "1":

  ac_cv_func_sigprocmask=${ac_cv_func_sigprocmask=yes}
...
  gl_cv_func_sigprocmask=${gl_cv_func_sigprocmask=1}

If I compare the configure output from a run with using the cache
(fails) with one that doesn't use the cache (succeeds) the only
difference of interest is:

  @@ -378,7 +379,7 @@
   checking whether program_invocation_name is declared... yes
   checking whether program_invocation_short_name is declared... yes
   checking for raise... yes
  -checking for sigprocmask... 1
  +checking for sigprocmask... yes
   checking for readline... yes
   checking how to link with libreadline... -lreadline
   checking for readline/readline.h... yes
  @@ -398,7 +399,7 @@
   checking for sighandler_t... yes
   checking for signbit macro... yes
   checking for signbit compiler built-ins... yes
  -checking for sigprocmask... 1
  +checking for sigprocmask... yes
   checking for stdint.h... yes
   checking for SIZE_MAX... yes
   checking for snprintf... yes

My suspicion is that if one of those values is obtained from the cache
rather than being computed, then some side-effect of the check is not
happening and this is causing the wrong result.

I will disable autoconf caching but it would be great if this issue
could be addressed...  I will keep the build artifacts around if people
need more details etc.

Cheers!




bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

2020-08-02 Thread Paul Smith
The latest Bison release 3.7.1 is not compiling for me, and it appears
to be a gnulib issue.

Here's the failure:

gcc -DEXEEXT=\"\" -I. -I./lib -Ibison-3.7.1 -Ibison-3.7.1/lib \
  -DDEFAULT_TEXT_DOMAIN=\"bison-gnulib\" -march=nehalem -mtune=intel \
  -ffile-prefix-map=bison-3.7.1/= -O2 -fPIC -static-libgcc \
  -MT lib/libbison_a-quotearg.o -MD -MP \
  -MF lib/.deps/libbison_a-quotearg.Tpo -c -olib/libbison_a-quotearg.o \
  `test -f 'lib/quotearg.c' || echo 'bison-3.7.1/'`lib/quotearg.c
In file included from /usr/include/sys/param.h:28,
 from bison-3.7.1/lib/minmax.h:34,
 from bison-3.7.1/lib/quotearg.c:33:
./lib/signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative
  682 | typedef int verify_NSIG_constraint[NSIG <= 32 ? 1 : -1];
  | ^~
make[2]: *** [Makefile:5457: lib/libbison_a-quotearg.o] Error 1

All of these files (quotearg.c, minmax.h, signal.h) are coming from
gnulib.

Obviously, Linux has a lot more than 32 signals defined normally... so
I feel like I'm missing something here about what this check is
supposed to do and how it's supposed to work...

Anyone have any ideas?




oset: Add an 'iterator_atleast' operation

2020-08-02 Thread Bruno Haible
In an application that uses an ordered set (gl_oset), I need an iterator
that starts at the first element that has a value >= threshold. And it
should be fast in the case when only 1 or 2 or 3 elements from that iterator
are needed, but the entire set is large.
It can't be realized with the existing API that provides (separately)
  - a function to find the first element that has a value >= threshold,
  - a function that returns at iterator that starts at the beginning.
This patch implements it.


2020-08-02  Bruno Haible  

oset: Add an 'iterator_atleast' operation.
* lib/gl_array_oset.c (gl_array_indexof_atleast): New function,
extracted from gl_array_search_atleast.
(gl_array_search_atleast): Use it.
(gl_array_iterator_atleast): New function.
(gl_array_oset_implementation): Use it.
* lib/gl_anytree_oset.h (gl_tree_iterator_atleast): New function.
* lib/gl_avltree_oset.c (gl_avltree_oset_implementation): Use it.
* lib/gl_rbtree_oset.c (gl_rbtree_oset_implementation): Likewise.
* lib/gl_oset.h (struct gl_oset_implementation): Add 'iterator_atleast'
member.
(gl_oset_iterator_atleast): New function.
* lib/gl_oset.hh (gl_OSet): Add 'begin_atleast' member.
(gl_OSet::iterator): Add another auxiliary constructor.
* tests/test-array_oset.c (is_at_least, gl_sortedlist_indexof_atleast):
New functions.
(main): Test also gl_oset_iterator_atleast.
* tests/test-avltree_oset.c (is_at_least): New function.
(main): Test also gl_oset_iterator_atleast.
* tests/test-rbtree_oset.c (is_at_least): New function.
(main): Test also gl_oset_iterator_atleast.
* tests/test-oset-c++.cc (is_at_most): New function.
(main): Test also gl_OSet::begin_atleast.

diff --git a/lib/gl_anytree_oset.h b/lib/gl_anytree_oset.h
index 8a64229..10957c0 100644
--- a/lib/gl_anytree_oset.h
+++ b/lib/gl_anytree_oset.h
@@ -375,6 +375,52 @@ gl_tree_iterator (gl_oset_t set)
   return result;
 }
 
+static gl_oset_iterator_t
+gl_tree_iterator_atleast (gl_oset_t set,
+  gl_setelement_threshold_fn threshold_fn,
+  const void *threshold)
+{
+  gl_oset_iterator_t result;
+  gl_oset_node_t node;
+
+  result.vtable = set->base.vtable;
+  result.set = set;
+  /* End point is past the rightmost node.  */
+  result.q = NULL;
+#if defined GCC_LINT || defined lint
+  result.i = 0;
+  result.j = 0;
+  result.count = 0;
+#endif
+
+  for (node = set->root; node != NULL; )
+{
+  if (! threshold_fn (node->value, threshold))
+node = node->right;
+  else
+{
+  /* We have an element >= THRESHOLD.  But we need the leftmost such
+ element.  */
+  gl_oset_node_t found = node;
+  node = node->left;
+  for (; node != NULL; )
+{
+  if (! threshold_fn (node->value, threshold))
+node = node->right;
+  else
+{
+  found = node;
+  node = node->left;
+}
+}
+  result.p = found;
+  return result;
+}
+}
+  result.p = NULL;
+  return result;
+}
+
 static bool
 gl_tree_iterator_next (gl_oset_iterator_t *iterator, const void **eltp)
 {
diff --git a/lib/gl_array_oset.c b/lib/gl_array_oset.c
index 86fb747..f44d6b0 100644
--- a/lib/gl_array_oset.c
+++ b/lib/gl_array_oset.c
@@ -107,11 +107,15 @@ gl_array_search (gl_oset_t set, const void *elt)
   return gl_array_indexof (set, elt) != (size_t)(-1);
 }
 
-static bool
-gl_array_search_atleast (gl_oset_t set,
- gl_setelement_threshold_fn threshold_fn,
- const void *threshold,
- const void **eltp)
+/* Searches the least element in the ordered set that compares greater or equal
+   to the given THRESHOLD.  The representation of the THRESHOLD is defined
+   by the THRESHOLD_FN.
+   Returns the position at which it was found, or gl_list_size (SET) if not
+   found.  */
+static size_t
+gl_array_indexof_atleast (gl_oset_t set,
+  gl_setelement_threshold_fn threshold_fn,
+  const void *threshold)
 {
   size_t count = set->count;
 
@@ -148,13 +152,29 @@ gl_array_search_atleast (gl_oset_t set,
   else
 high = mid2;
 }
-  *eltp = set->elements[low];
-  return true;
+  return low;
 }
 }
   while (low < high);
 }
-  return false;
+  return count;
+}
+
+static bool
+gl_array_search_atleast (gl_oset_t set,
+ gl_setelement_threshold_fn threshold_fn,
+ const void *threshold,
+ const void **eltp)
+{
+  size_t index = gl_array_indexof_atleast (set, threshold_fn, threshold);
+
+  if (index == set->count)
+return 

oset-c++, omap-c++: Remove restriction for search_atleast method

2020-08-02 Thread Bruno Haible
The threshold argument in the search_atleast method is meant to be unrelated
to the ELTYPE or KEYTYPE types, respectively.


2020-08-02  Bruno Haible  

oset-c++, omap-c++: Remove restriction for search_atleast method.
* lib/gl_oset.hh (gl_OSet::search_atleast): Allow the threshold to be of
a different type than the element.
* lib/gl_omap.hh (gl_OMap::search_atleast): Allow the threshold to be of
a different type than the key.

diff --git a/lib/gl_omap.hh b/lib/gl_omap.hh
index 1f892e4..903befb 100644
--- a/lib/gl_omap.hh
+++ b/lib/gl_omap.hh
@@ -89,8 +89,9 @@ public:
  THRESHOLD is defined by the THRESHOLD_FN.
  Returns true and stores the found pair in KEY and VALUE if found.
  Otherwise returns false.  */
-  bool search_atleast (bool (*threshold_fn) (KEYTYPE * /*key*/, KEYTYPE * 
/*threshold*/),
-   KEYTYPE * threshold,
+  template 
+  bool search_atleast (bool (*threshold_fn) (KEYTYPE * /*key*/, THT * 
/*threshold*/),
+   THT * threshold,
KEYTYPE *& key, VALUETYPE *& value) const
   { return gl_omap_search_atleast (_ptr, 
reinterpret_cast(threshold_fn), threshold, , 
); }
 
diff --git a/lib/gl_oset.hh b/lib/gl_oset.hh
index 5a72476..157b8b9 100644
--- a/lib/gl_oset.hh
+++ b/lib/gl_oset.hh
@@ -80,8 +80,9 @@ public:
  by the THRESHOLD_FN.
  Returns true and store the found element in ELT if found, otherwise 
returns
  false.  */
-  bool search_atleast (bool (*threshold_fn) (ELTYPE * /*elt*/, ELTYPE * 
/*threshold*/),
-   ELTYPE * threshold,
+  template 
+  bool search_atleast (bool (*threshold_fn) (ELTYPE * /*elt*/, THT * 
/*threshold*/),
+   THT * threshold,
ELTYPE *& elt) const
   { return gl_oset_search_atleast (_ptr, 
reinterpret_cast(threshold_fn), threshold, ); }
 




Re: signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

2020-08-02 Thread Tim Rühsen
On 02.08.20 15:41, Bruno Haible wrote:
> Tim Rühsen wrote:
>> The surrounding code in lib/signal.h is
>> #if 1
>> # if !0
> 
> Huh? HAVE_POSIX_SIGNALBLOCKING evaluates to 0 ?!
> 
> There was a change to m4/signalblocking.m4 recently, but for me it works.
> Can you take a look at the "checking for sigprocmask..." test in
> config.log?

Oh ouch, my bad.

Just recognized that i use a global configure cache that i didn't
remove. I assume that all the CI jobs suffer from the same.
This rarely happens - but updating gnulib is definitely worth removing
all configure caches.

I am really sorry to have wasted your time. The cache just didn't pop
into my mind :-(

Thank you very much !

Regards, Tim



signature.asc
Description: OpenPGP digital signature


Re: signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

2020-08-02 Thread Bruno Haible
Tim Rühsen wrote:
> The surrounding code in lib/signal.h is
> #if 1
> # if !0

Huh? HAVE_POSIX_SIGNALBLOCKING evaluates to 0 ?!

There was a change to m4/signalblocking.m4 recently, but for me it works.
Can you take a look at the "checking for sigprocmask..." test in
config.log?

Bruno




Re: signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

2020-08-02 Thread Bruno Haible
Hi Tim,

> after updating gnulib, I see this on all CI pipelines (Debian, Fedora,
> Alpine, Arch, ...):
> 
> In file included from /usr/include/x86_64-linux-gnu/sys/param.h:28,
>  from ./minmax.h:34,
>  from md2.c:30:
> ./signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative
>   682 | typedef int verify_NSIG_constraint[NSIG <= 32 ? 1 : -1];
>   | ^~
> make[3]: *** [Makefile:2261: md2.lo] Error 1

Where do you see this?
  https://gitlab.com/gnulib/gnulib-ci/-/jobs
  https://gitlab.com/gnulib/build-images/-/jobs
are fine.

The signal.h related stuff in Gnulib has not changed since February 2020.

To me, it looks like you are building a package that has "#define NSIG 64"
in its config.h. Or something like that...

Bruno




signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative

2020-08-02 Thread Tim Rühsen
Hey,

after updating gnulib, I see this on all CI pipelines (Debian, Fedora,
Alpine, Arch, ...):

In file included from /usr/include/x86_64-linux-gnu/sys/param.h:28,
 from ./minmax.h:34,
 from md2.c:30:
./signal.h:682:13: error: size of array 'verify_NSIG_constraint' is negative
  682 | typedef int verify_NSIG_constraint[NSIG <= 32 ? 1 : -1];
  | ^~
make[3]: *** [Makefile:2261: md2.lo] Error 1


The surrounding code in lib/signal.h is
#if 1
# if !0

#  ifndef GNULIB_defined_signal_blocking
#   define GNULIB_defined_signal_blocking 1
#  endif

/* Maximum signal number + 1.  */
#  ifndef NSIG
#   define NSIG 32
#  endif

/* This code supports only 32 signals.  */
#  if !GNULIB_defined_verify_NSIG_constraint
typedef int verify_NSIG_constraint[NSIG <= 32 ? 1 : -1];
#   define GNULIB_defined_verify_NSIG_constraint 1
#  endif

# endif


Regards, Tim



signature.asc
Description: OpenPGP digital signature