bug#24602: grep-2.26 make check fails on i686

[Paul Eggert]

On 10/04/2016 06:33 AM, Jaroslav Skarvada wrote:

In fact it's glibc, affected version: glibc-2.24.90-8


I sent a heads-up about this to libc-alpha, here:

https://sourceware.org/ml/libc-alpha/2016-10/msg00044.html

Something like the attached gnulib patch should work around the problem, 
but I wonder whether we should bother given that it's bleeding-edge 
glibc that will get fixed soon and that the failure is so unimportant.


diff --git a/doc/posix-headers/limits.texi b/doc/posix-headers/limits.texi
index 7658326..135a51a 100644
--- a/doc/posix-headers/limits.texi
+++ b/doc/posix-headers/limits.texi
@@ -14,6 +14,9 @@ IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin 1.5.x, mingw, MSVC 9, Interix 3.
 @item
 Macros like @code{CHAR_WIDTH} are not defined on some platforms:
 glibc 2.24, many others.
+@item
+Macros like @code{LONG_WIDTH} have the wrong value on some platforms:
+glibc-2.24.90-8.fc26.i686.
 @end itemize
 
 Portability problems not fixed by Gnulib:
diff --git a/lib/limits.in.h b/lib/limits.in.h
index 9a4f9f4..b616a4e 100644
--- a/lib/limits.in.h
+++ b/lib/limits.in.h
@@ -44,6 +44,21 @@
 
 /* Macros specified by ISO/IEC TS 18661-1:2014.  */
 
+/* Work around a bug in glibc-2.24.90-8.fc26.i686.  */
+#if defined LONG_WIDTH && LONG_MAX >> (LONG_WIDTH - 2) != 1
+# undef CHAR_WIDTH
+# undef SCHAR_WIDTH
+# undef UCHAR_WIDTH
+# undef SHRT_WIDTH
+# undef USHRT_WIDTH
+# undef INT_WIDTH
+# undef UINT_WIDTH
+# undef LONG_WIDTH
+# undef ULONG_WIDTH
+# undef LLONG_WIDTH
+# undef ULLONG_WIDTH
+#endif
+
 #if (! defined ULLONG_WIDTH \
  && (defined _GNU_SOURCE || defined __STDC_WANT_IEC_60559_BFP_EXT__))
 # define CHAR_WIDTH _GL_INTEGER_WIDTH (CHAR_MIN, CHAR_MAX)
diff --git a/m4/limits-h.m4 b/m4/limits-h.m4
index 31fdf0a..fd12c57 100644
--- a/m4/limits-h.m4
+++ b/m4/limits-h.m4
@@ -18,6 +18,9 @@ AC_DEFUN_ONCE([gl_LIMITS_H],
#define __STDC_WANT_IEC_60559_BFP_EXT__ 1
   #endif
   #include 
+  #if LONG_MAX >> (LONG_WIDTH - 2) != 1
+error LONG_WIDTH is wrong, e.g., glibc-2.24.90-8;
+  #endif
   int ullw = ULLONG_WIDTH;]])],
[gl_cv_header_limits_width=yes],
[gl_cv_header_limits_width=no])])

bug#24602: grep-2.26 make check fails on i686

[Jim Meyering]

tags 24602 notabug
stop

On Tue, Oct 4, 2016 at 6:33 AM, Jaroslav Skarvada  wrote:
...
>> GCC Fedora bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1381582
>>
>> thanks & regards
>>
>> Jaroslav
>>
>
> In fact it's glibc, affected version: glibc-2.24.90-8

Thanks for following through.

bug#24602: grep-2.26 make check fails on i686

[Jaroslav Skarvada]

- Original Message -
> 
> 
> - Original Message -
> > Thanks for reporting a problem. Please run the attached program width.c
> > on your platform with your C compiler and the compiler flags you're
> > using to build 'grep'. Although width.c should output "sizeof(long)=4
> > LONG_WIDTH=32 LONG_MIN=-2147483648 LONG_MAX=2147483647", it appears from
> > your build log
> > 
> > that width.c will output "sizeof(long)=4 LONG_WIDTH=64
> > LONG_MIN=-2147483648 LONG_MAX=2147483647", i.e., LONG_WIDTH will be wrong.
> >
> With 'gcc -D_GNU_SOURCE -o width width.c':
> sizeof(long)=4 LONG_WIDTH=64 LONG_MIN=-2147483648 LONG_MAX=2147483647
> 
> > If I'm right, please investigate why LONG_WIDTH is wrong for your build
> > configuration. The symptoms are that of a 32-bit build with a 64-bit C
> > preprocessor, at least as far as __LONG_WIDTH__ is concerned. If this is
> > a common-enough platform error then I suppose Gnulib should work around
> > the implementation bug.
> >
> Yes LONG_WIDTH is 64 and it shouldn't be. I think the reason is the
> following new code from the /usr/include/limits.h:
> 
> /* The integer width macros are not defined by GCC's  before
>GCC 7, or if _GNU_SOURCE rather than
>__STDC_WANT_IEC_60559_BFP_EXT__ is used to enable this feature.  */
> #if __GLIBC_USE (IEC_60559_BFP_EXT)
> ...
> # if LONG_MAX == 0x7fffL
> #  ifndef LONG_WIDTH
> #   define LONG_WIDTH 32
> #  endif
> #  ifndef ULONG_WIDTH
> #   define ULONG_WIDTH 32
> #  endif
> # else
> #  ifndef LONG_WIDTH
> #   define LONG_WIDTH 64
> #  endif
> #  ifndef ULONG_WIDTH
> #   define ULONG_WIDTH 64
> #  endif
> # endif
> 
> but LONG_MAX is not defined in the check, it's defined later thus LONG_WIDTH
> is
> incorrectly set to the 64 even on 32 bit platforms. I am going to open gcc
> bug
> 
GCC Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1381582

thanks & regards

Jaroslav

bug#24602: grep-2.26 make check fails on i686

[Jaroslav Skarvada]

- Original Message -
> 
> 
> - Original Message -
> > 
> > 
> > - Original Message -
> > > Thanks for reporting a problem. Please run the attached program width.c
> > > on your platform with your C compiler and the compiler flags you're
> > > using to build 'grep'. Although width.c should output "sizeof(long)=4
> > > LONG_WIDTH=32 LONG_MIN=-2147483648 LONG_MAX=2147483647", it appears from
> > > your build log
> > > 
> > > that width.c will output "sizeof(long)=4 LONG_WIDTH=64
> > > LONG_MIN=-2147483648 LONG_MAX=2147483647", i.e., LONG_WIDTH will be
> > > wrong.
> > >
> > With 'gcc -D_GNU_SOURCE -o width width.c':
> > sizeof(long)=4 LONG_WIDTH=64 LONG_MIN=-2147483648 LONG_MAX=2147483647
> > 
> > > If I'm right, please investigate why LONG_WIDTH is wrong for your build
> > > configuration. The symptoms are that of a 32-bit build with a 64-bit C
> > > preprocessor, at least as far as __LONG_WIDTH__ is concerned. If this is
> > > a common-enough platform error then I suppose Gnulib should work around
> > > the implementation bug.
> > >
> > Yes LONG_WIDTH is 64 and it shouldn't be. I think the reason is the
> > following new code from the /usr/include/limits.h:
> > 
> > /* The integer width macros are not defined by GCC's  before
> >GCC 7, or if _GNU_SOURCE rather than
> >__STDC_WANT_IEC_60559_BFP_EXT__ is used to enable this feature.  */
> > #if __GLIBC_USE (IEC_60559_BFP_EXT)
> > ...
> > # if LONG_MAX == 0x7fffL
> > #  ifndef LONG_WIDTH
> > #   define LONG_WIDTH 32
> > #  endif
> > #  ifndef ULONG_WIDTH
> > #   define ULONG_WIDTH 32
> > #  endif
> > # else
> > #  ifndef LONG_WIDTH
> > #   define LONG_WIDTH 64
> > #  endif
> > #  ifndef ULONG_WIDTH
> > #   define ULONG_WIDTH 64
> > #  endif
> > # endif
> > 
> > but LONG_MAX is not defined in the check, it's defined later thus
> > LONG_WIDTH
> > is
> > incorrectly set to the 64 even on 32 bit platforms. I am going to open gcc
> > bug
> > 
> GCC Fedora bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1381582
> 
> thanks & regards
> 
> Jaroslav
> 

In fact it's glibc, affected version: glibc-2.24.90-8

thanks & regards

Jaroslav

bug#24602: grep-2.26 make check fails on i686

[Jaroslav Skarvada]

- Original Message -
> Thanks for reporting a problem. Please run the attached program width.c
> on your platform with your C compiler and the compiler flags you're
> using to build 'grep'. Although width.c should output "sizeof(long)=4
> LONG_WIDTH=32 LONG_MIN=-2147483648 LONG_MAX=2147483647", it appears from
> your build log
> 
> that width.c will output "sizeof(long)=4 LONG_WIDTH=64
> LONG_MIN=-2147483648 LONG_MAX=2147483647", i.e., LONG_WIDTH will be wrong.
>
With 'gcc -D_GNU_SOURCE -o width width.c':
sizeof(long)=4 LONG_WIDTH=64 LONG_MIN=-2147483648 LONG_MAX=2147483647

> If I'm right, please investigate why LONG_WIDTH is wrong for your build
> configuration. The symptoms are that of a 32-bit build with a 64-bit C
> preprocessor, at least as far as __LONG_WIDTH__ is concerned. If this is
> a common-enough platform error then I suppose Gnulib should work around
> the implementation bug.
>
Yes LONG_WIDTH is 64 and it shouldn't be. I think the reason is the
following new code from the /usr/include/limits.h:

/* The integer width macros are not defined by GCC's  before
   GCC 7, or if _GNU_SOURCE rather than
   __STDC_WANT_IEC_60559_BFP_EXT__ is used to enable this feature.  */
#if __GLIBC_USE (IEC_60559_BFP_EXT)
...
# if LONG_MAX == 0x7fffL
#  ifndef LONG_WIDTH
#   define LONG_WIDTH 32
#  endif
#  ifndef ULONG_WIDTH
#   define ULONG_WIDTH 32
#  endif
# else
#  ifndef LONG_WIDTH
#   define LONG_WIDTH 64
#  endif
#  ifndef ULONG_WIDTH
#   define ULONG_WIDTH 64
#  endif
# endif

but LONG_MAX is not defined in the check, it's defined later thus LONG_WIDTH is
incorrectly set to the 64 even on 32 bit platforms. I am going to open gcc bug

thanks & regards

Jaroslav

bug#24602: grep-2.26 make check fails on i686

[Jim Meyering]

On Mon, Oct 3, 2016 at 2:48 PM, Jaroslav Skarvada  wrote:
> Reproduced on Fedora Rawhide, gcc-6.2.1:
>
> $ make check
> ...
> In file included from test-limits-h.c:23:0:
> test-limits-h.c:28:17: warning: right shift count >= width of type 
> [-Wshift-count-overflow]
>verify ((max) >> ((width) - 1 - ((min) < 0)) == 1)

Thanks for the report. So far, I have been unable to reproduce that: I
built on a native i686 system using a year old snapshot of gcc-6.0.0,
and all tests passed.

bug#24602: grep-2.26 make check fails on i686

[Paul Eggert]

Thanks for reporting a problem. Please run the attached program width.c 
on your platform with your C compiler and the compiler flags you're 
using to build 'grep'. Although width.c should output "sizeof(long)=4 
LONG_WIDTH=32 LONG_MIN=-2147483648 LONG_MAX=2147483647", it appears from 
your build log 
 
that width.c will output "sizeof(long)=4 LONG_WIDTH=64 
LONG_MIN=-2147483648 LONG_MAX=2147483647", i.e., LONG_WIDTH will be wrong.


If I'm right, please investigate why LONG_WIDTH is wrong for your build 
configuration. The symptoms are that of a 32-bit build with a 64-bit C 
preprocessor, at least as far as __LONG_WIDTH__ is concerned. If this is 
a common-enough platform error then I suppose Gnulib should work around 
the implementation bug.


If I'm wrong, please run the following commands and send a compressed 
copy of resulting width.i file.


cd gnulib-tests
gcc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I..  -DIN_GREP_GNULIB_TESTS=1 -I. 
-I. -I.. -I./.. -I../lib -I./../lib -I/usr/include/pcre  -O2 -g -pipe 
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 
-mtune=atom -fasynchronous-unwind-tables -E -dD test-limits-h.c >width.i


You mentioned gcc-6.2.1. For what it's worth I didn't observe a problem 
on Fedora 24, which has gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2). A 
compressed copy of my width.i file is attached, for comparison. I built 
with "./configure --without-included-regex --disable-silent-rules 
CFLAGS='-O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 
-mtune=atom -fasynchronous-unwind-tables'".
#include 
#include 

int
main (void)
{
  int n = sizeof (long);
  printf ("sizeof(long)=%d LONG_WIDTH=%d LONG_MIN=%ld LONG_MAX=%ld\n",
  n, LONG_WIDTH, LONG_MIN, LONG_MAX);
  return 0;
}


width.i.gz
Description: application/gzip

bug#24602: grep-2.26 make check fails on i686

[Assaf Gordon]

Hello,

> On Oct 3, 2016, at 17:48, Jaroslav Skarvada  wrote:
> 
> Reproduced on Fedora Rawhide, gcc-6.2.1:
> 
> [...]
> Full build log:
> https://kojipkgs.fedoraproject.org/work/tasks/8044/15928044/build.log
> x86_64 seems to work OK

As a side note,
these are gnulib tests which fail to compile, grep-2.26 is built successfully 
and its test do not fail (based on the log above).

I tested with it Ubuntu 15.04-i686 with gcc 4.9.2 and there were no failures - 
I'll create a newer i686 test VM to catch these potential failures...

-assaf

bug#24602: grep-2.26 make check fails on i686

[Jaroslav Skarvada]

Reproduced on Fedora Rawhide, gcc-6.2.1:

$ make check
...
In file included from test-limits-h.c:23:0:
test-limits-h.c:28:17: warning: right shift count >= width of type 
[-Wshift-count-overflow]
   verify ((max) >> ((width) - 1 - ((min) < 0)) == 1)
 ^
../lib/verify.h:251:31: note: in definition of macro 'verify'
 #define verify(R) _GL_VERIFY (R, "verify (" #R ")")
   ^
test-limits-h.c:37:1: note: in expansion of macro 'verify_width'
 verify_width (LONG_WIDTH, LONG_MIN, LONG_MAX);
 ^~~~
../lib/verify.h:207:21: error: static assertion failed: "verify ((0x7fffL) 
>> ((64) - 1 - (((-0x7fffL - 1L)) < 0)) == 1)"
 # define _GL_VERIFY _Static_assert
 ^
../lib/verify.h:251:19: note: in expansion of macro '_GL_VERIFY'
 #define verify(R) _GL_VERIFY (R, "verify (" #R ")")
   ^~
test-limits-h.c:28:3: note: in expansion of macro 'verify'
   verify ((max) >> ((width) - 1 - ((min) < 0)) == 1)
   ^~
test-limits-h.c:37:1: note: in expansion of macro 'verify_width'
 verify_width (LONG_WIDTH, LONG_MIN, LONG_MAX);
 ^~~~
test-limits-h.c:28:17: warning: right shift count >= width of type 
[-Wshift-count-overflow]
   verify ((max) >> ((width) - 1 - ((min) < 0)) == 1)
 ^
../lib/verify.h:251:31: note: in definition of macro 'verify'
 #define verify(R) _GL_VERIFY (R, "verify (" #R ")")
   ^
test-limits-h.c:38:1: note: in expansion of macro 'verify_width'
 verify_width (ULONG_WIDTH, 0, ULONG_MAX);
 ^~~~
../lib/verify.h:207:21: error: static assertion failed: "verify (((0x7fffL 
* 2UL + 1UL)) >> ((64) - 1 - ((0) < 0)) == 1)"
 # define _GL_VERIFY _Static_assert
 ^
../lib/verify.h:251:19: note: in expansion of macro '_GL_VERIFY'
 #define verify(R) _GL_VERIFY (R, "verify (" #R ")")
   ^~
test-limits-h.c:28:3: note: in expansion of macro 'verify'
   verify ((max) >> ((width) - 1 - ((min) < 0)) == 1)
   ^~
test-limits-h.c:38:1: note: in expansion of macro 'verify_width'
 verify_width (ULONG_WIDTH, 0, ULONG_MAX);
 ^~~~

Full build log:
https://kojipkgs.fedoraproject.org/work/tasks/8044/15928044/build.log
x86_64 seems to work OK

regards

Jaroslav