* Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
@ 2012-02-12 11:02 Alan Mackenzie
2012-02-12 21:31 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2012-02-12 11:02 UTC (permalink / raw
To: emacs-devel
Hi, Emacs.
While trying to build the latest bzr version, I get this error:
alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
. Is this just me, or is it happening to others? Any change of a fix?
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
2012-02-12 11:02 Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative' Alan Mackenzie
@ 2012-02-12 21:31 ` Paul Eggert
2012-02-13 13:07 ` Alan Mackenzie
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2012-02-12 21:31 UTC (permalink / raw
To: Alan Mackenzie; +Cc: emacs-devel
On 02/12/2012 03:02 AM, Alan Mackenzie wrote:
> alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
I am not seeing this problem (trunk bzr 107261)
on Fedora 15 x86-64 with GCC 4.6.2.
That diagnostic is because the following static assertion
is failing:
verify (INT_MAX <= PTRDIFF_MAX);
which suggests that your compilation environment is misconfigured
somehow -- I don't know of any platforms where INT_MAX
is greater than PTRDIFF_MAX.
I suggest running 'make distclean; ./autogen.sh; ./configure; make',
or if that fails a fresh checkout.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
2012-02-12 21:31 ` Paul Eggert
@ 2012-02-13 13:07 ` Alan Mackenzie
2012-02-13 16:57 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2012-02-13 13:07 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
Hi, Paul.
On Sun, Feb 12, 2012 at 01:31:28PM -0800, Paul Eggert wrote:
> On 02/12/2012 03:02 AM, Alan Mackenzie wrote:
> > alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
> I am not seeing this problem (trunk bzr 107261)
> on Fedora 15 x86-64 with GCC 4.6.2.
> That diagnostic is because the following static assertion
> is failing:
> verify (INT_MAX <= PTRDIFF_MAX);
Hmmm. I've grepped for "negative width in bit-field" and
_gl_verify_error_if_negative and found neither. Come to that, I haven't
found verify either.
How can the compiler transform "INT_MAX <= PTRDIFF_MAX" into a message
about bit-field widths?
Is this not, perhaps, a bug in the compiler itself?
> which suggests that your compilation environment is misconfigured
> somehow -- I don't know of any platforms where INT_MAX
> is greater than PTRDIFF_MAX.
As far as I can make out, it isn't. INT_MAX is 2^31-1 (checked by an
#ifdef and #warning). PTRDIFF_MAX I couldn't verify directly, but in
/usr/include/limits.h it is either 2^31-1 or 2^63-1 (I have a 64-bit
machine).
> I suggest running 'make distclean; ./autogen.sh; ./configure; make',
> or if that fails a fresh checkout.
None of that worked. :-(
I'm going to try googling for that error message.
Thanks!
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
2012-02-13 13:07 ` Alan Mackenzie
@ 2012-02-13 16:57 ` Paul Eggert
2012-02-13 20:34 ` Alan Mackenzie
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2012-02-13 16:57 UTC (permalink / raw
To: Alan Mackenzie; +Cc: emacs-devel
On 02/13/2012 05:07 AM, Alan Mackenzie wrote:
> How can the compiler transform "INT_MAX <= PTRDIFF_MAX" into a message
> about bit-field widths?
That message is generated for compilers that are not known to
support C11-style static assertions
<http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01188.html>.
In GCC 4.6.0 and later, verify(X) simply expands to _Static_assert(X).
Other compilers (including older GCCs) are not known to have
_Static_assert, so verify(X) expands to:
struct { unsigned _gl_verify_error_if_negative: (X) ? 1 : -1; }
which causes a compile-time error if X is false (the desired
effect); as you've noticed, the diagnostic isn't as nice as
with GCC 4.6.0 and later.
This is implemented in lib/verify.h -- more commentary is there.
My guess is that PTRDIFF_MAX is set incorrectly in your implementation.
Emacs's 'configure' script attempts to detect that, and replace it
with a correct PTRDIFF_MAX, but perhaps we need to improve 'configure'
so that it detects the problem with your implementation.
Can you send the compressed "gcc -E ..." output of the offending
compilation, and the contents of 'config.log' and 'src/config.h' and
(if present) 'lib/stdint.h'? That should help debug the situation.
Also, if you could determine which standard header is defining
ptrdiff_t and PTRDIFF_MAX, and what they're defined to, that might
help.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
2012-02-13 16:57 ` Paul Eggert
@ 2012-02-13 20:34 ` Alan Mackenzie
2012-02-13 20:50 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2012-02-13 20:34 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]
Hi, Paul,
On Mon, Feb 13, 2012 at 08:57:36AM -0800, Paul Eggert wrote:
> On 02/13/2012 05:07 AM, Alan Mackenzie wrote:
> My guess is that PTRDIFF_MAX is set incorrectly in your implementation.
> Emacs's 'configure' script attempts to detect that, and replace it
> with a correct PTRDIFF_MAX, but perhaps we need to improve 'configure'
> so that it detects the problem with your implementation.
> Can you send the compressed "gcc -E ..." output of the offending
> compilation, and the contents of 'config.log' and 'src/config.h' and
> (if present) 'lib/stdint.h'? That should help debug the situation.
> Also, if you could determine which standard header is defining
> ptrdiff_t and PTRDIFF_MAX, and what they're defined to, that might
> help.
I think i've tracked down PTRDIFF_MAX's value from looking at the after
CPP version of xnmalloc: Together with my evaluation, it looks like
this:
(((1) ? ~ ((1) ? (- ((0l) + 1) << ((0) ? (0) - 1 : 0)) : (0l)) : ((((0l) + 1) << ((0) ? (0) - 1 - (1) : 0)) - 1) * 2 + 1))
~ ((1) ? (- ((0l) + 1) << ((0) ? (0) - 1 : 0)) : (0l))
~ (- ((0l) + 1) << ((0) ? (0) - 1 : 0))
~ (- 2 << 0 )
~ -2
1
Somehow I must have made a mistake, surely. PTRDIFF_MAX cannot be 1.
This definition of PTRDIFF_MAX can only have come from
emacs/lib/stdint.h, because it is here defined as a complex macro whereas
the competing version in /usr/include/stdint.h just has 2147483647 and
the 64-bit equivalent. I can't find the definition of ptrdiff_t.
Anyhow, I've attached the "gcc -E ...", config.log, src/config.h and
lib/stdint.h.
--
Alan Mackenzie (Nuremberg, Germany).
[-- Attachment #2: stdint.h.bz2 --]
[-- Type: application/x-bzip2, Size: 4524 bytes --]
[-- Attachment #3: config.h.bz2 --]
[-- Type: application/x-bzip2, Size: 10326 bytes --]
[-- Attachment #4: config.log.bz2 --]
[-- Type: application/x-bzip2, Size: 30532 bytes --]
[-- Attachment #5: alloc.cpp.bz2 --]
[-- Type: application/x-bzip2, Size: 88364 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
2012-02-13 20:34 ` Alan Mackenzie
@ 2012-02-13 20:50 ` Paul Eggert
2012-02-13 22:41 ` Alan Mackenzie
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2012-02-13 20:50 UTC (permalink / raw
To: Alan Mackenzie; +Cc: emacs-devel
Your compilation environment appears to have a problem, in this part of
config.log:
configure:17999: checking for bit size of ptrdiff_t
configure:18004: gcc -std=gnu99 -o conftest -g -O2 -Wl,-znocombreloc conftest.c -lncurses -llockfile -lm -lxml2 -lSM -lICE -lXrender -lXft -lgnutls -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lMagickWand -lMagickCore -pthread -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lX11 -lpthread -ldbus-1 -lpthread -lrt >&5
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libMagickCore.so.4, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libMagickWand.so, not found (try using -rpath or -rpath-link)
configure:18004: $? = 0
configure:18004: ./conftest
./conftest: error while loading shared libraries: libMagickCore.so.4: cannot open shared object file: No such file or directory
configure:18004: $? = 127
configure: program exited with status 127
You probably need to fix this, for other reasons. But before you fix it,
could you please see whether the following patch avoids the static assertion failure?
Thanks.
diff --git a/lib/stdint.in.h b/lib/stdint.in.h
index 54ec7e0..08f362e 100644
--- a/lib/stdint.in.h
+++ b/lib/stdint.in.h
@@ -481,6 +481,7 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
/* 7.18.3. Limits of other integer types */
/* ptrdiff_t limits */
+#if @APPLE_UNIVERSAL_BUILD@ || @BITSIZEOF_PTRDIFF_T@
#undef PTRDIFF_MIN
#undef PTRDIFF_MAX
#if @APPLE_UNIVERSAL_BUILD@
@@ -497,8 +498,10 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
# define PTRDIFF_MAX \
_STDINT_MAX (1, @BITSIZEOF_PTRDIFF_T@, 0@PTRDIFF_T_SUFFIX@)
#endif
+#endif
/* sig_atomic_t limits */
+#if @BITSIZEOF_SIG_ATOMIC_T@
#undef SIG_ATOMIC_MIN
#undef SIG_ATOMIC_MAX
#define SIG_ATOMIC_MIN \
@@ -507,9 +510,10 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
#define SIG_ATOMIC_MAX \
_STDINT_MAX (@HAVE_SIGNED_SIG_ATOMIC_T@, @BITSIZEOF_SIG_ATOMIC_T@, \
0@SIG_ATOMIC_T_SUFFIX@)
-
+#endif
/* size_t limit */
+#if @APPLE_UNIVERSAL_BUILD@ || @BITSIZEOF_SIZE_T@
#undef SIZE_MAX
#if @APPLE_UNIVERSAL_BUILD@
# ifdef _LP64
@@ -520,6 +524,7 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
#else
# define SIZE_MAX _STDINT_MAX (0, @BITSIZEOF_SIZE_T@, 0@SIZE_T_SUFFIX@)
#endif
+#endif
/* wchar_t limits */
/* Get WCHAR_MIN, WCHAR_MAX.
@@ -537,20 +542,24 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
# include <wchar.h>
# undef _GL_JUST_INCLUDE_SYSTEM_WCHAR_H
#endif
+#if @BITSIZEOF_WCHAR_T@
#undef WCHAR_MIN
#undef WCHAR_MAX
#define WCHAR_MIN \
_STDINT_MIN (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0@WCHAR_T_SUFFIX@)
#define WCHAR_MAX \
_STDINT_MAX (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0@WCHAR_T_SUFFIX@)
+#endif
/* wint_t limits */
+#if @BITSIZEOF_WINT_T@
#undef WINT_MIN
#undef WINT_MAX
#define WINT_MIN \
_STDINT_MIN (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0@WINT_T_SUFFIX@)
#define WINT_MAX \
_STDINT_MAX (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0@WINT_T_SUFFIX@)
+#endif
/* 7.18.4. Macros for integer constants */
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative'
2012-02-13 20:50 ` Paul Eggert
@ 2012-02-13 22:41 ` Alan Mackenzie
0 siblings, 0 replies; 7+ messages in thread
From: Alan Mackenzie @ 2012-02-13 22:41 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
Hello, Paul.
On Mon, Feb 13, 2012 at 12:50:14PM -0800, Paul Eggert wrote:
> Your compilation environment appears to have a problem, in this part of
> config.log:
> configure:17999: checking for bit size of ptrdiff_t
> configure:18004: gcc -std=gnu99 -o conftest -g -O2 -Wl,-znocombreloc conftest.c -lncurses -llockfile -lm -lxml2 -lSM -lICE -lXrender -lXft -lgnutls -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lMagickWand -lMagickCore -pthread -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lX11 -lpthread -ldbus-1 -lpthread -lrt >&5
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libMagickCore.so.4, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libMagickWand.so, not found (try using -rpath or -rpath-link)
> configure:18004: $? = 0
> configure:18004: ./conftest
> ./conftest: error while loading shared libraries: libMagickCore.so.4: cannot open shared object file: No such file or directory
> configure:18004: $? = 127
> configure: program exited with status 127
Yes. Somehow that was the problem. I run Gentoo Gnu, and somehow hadn't
got around to rebuilding stuff when libMagickCore.so upgraded from .4 to
.5. Somehow. subconsciously, I never expected a library with a name like
that to have anything to do with Emacs. Anyhow, I did this build in a
separate directory structure and I've still got the debris from the
original troubled one.
> You probably need to fix this, for other reasons. But before you fix it,
> could you please see whether the following patch avoids the static assertion failure?
> Thanks.
Sorry, I was in too much of a hurry. I'll see if I can restore the two
programs concerned, so that they link again with libM..Core.so.4.
Interestingly, my ./configure run was stuttering fairly badly when it
wasn't working - on some sequences of tests, the disk drives were
chuntering back and forth as the tests went by at, perhaps, 2 per
second.
> diff --git a/lib/stdint.in.h b/lib/stdint.in.h
> index 54ec7e0..08f362e 100644
> --- a/lib/stdint.in.h
> +++ b/lib/stdint.in.h
> @@ -481,6 +481,7 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
> /* 7.18.3. Limits of other integer types */
> /* ptrdiff_t limits */
> +#if @APPLE_UNIVERSAL_BUILD@ || @BITSIZEOF_PTRDIFF_T@
> #undef PTRDIFF_MIN
> #undef PTRDIFF_MAX
> #if @APPLE_UNIVERSAL_BUILD@
> @@ -497,8 +498,10 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
> # define PTRDIFF_MAX \
> _STDINT_MAX (1, @BITSIZEOF_PTRDIFF_T@, 0@PTRDIFF_T_SUFFIX@)
> #endif
> +#endif
> /* sig_atomic_t limits */
> +#if @BITSIZEOF_SIG_ATOMIC_T@
> #undef SIG_ATOMIC_MIN
> #undef SIG_ATOMIC_MAX
> #define SIG_ATOMIC_MIN \
> @@ -507,9 +510,10 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
> #define SIG_ATOMIC_MAX \
> _STDINT_MAX (@HAVE_SIGNED_SIG_ATOMIC_T@, @BITSIZEOF_SIG_ATOMIC_T@, \
> 0@SIG_ATOMIC_T_SUFFIX@)
> -
> +#endif
> /* size_t limit */
> +#if @APPLE_UNIVERSAL_BUILD@ || @BITSIZEOF_SIZE_T@
> #undef SIZE_MAX
> #if @APPLE_UNIVERSAL_BUILD@
> # ifdef _LP64
> @@ -520,6 +524,7 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
> #else
> # define SIZE_MAX _STDINT_MAX (0, @BITSIZEOF_SIZE_T@, 0@SIZE_T_SUFFIX@)
> #endif
> +#endif
> /* wchar_t limits */
> /* Get WCHAR_MIN, WCHAR_MAX.
> @@ -537,20 +542,24 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
> # include <wchar.h>
> # undef _GL_JUST_INCLUDE_SYSTEM_WCHAR_H
> #endif
> +#if @BITSIZEOF_WCHAR_T@
> #undef WCHAR_MIN
> #undef WCHAR_MAX
> #define WCHAR_MIN \
> _STDINT_MIN (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0@WCHAR_T_SUFFIX@)
> #define WCHAR_MAX \
> _STDINT_MAX (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0@WCHAR_T_SUFFIX@)
> +#endif
> /* wint_t limits */
> +#if @BITSIZEOF_WINT_T@
> #undef WINT_MIN
> #undef WINT_MAX
> #define WINT_MIN \
> _STDINT_MIN (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0@WINT_T_SUFFIX@)
> #define WINT_MAX \
> _STDINT_MAX (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0@WINT_T_SUFFIX@)
> +#endif
> /* 7.18.4. Macros for integer constants */
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-02-13 22:41 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-12 11:02 Building: alloc.c:766:1: error: negative width in bit-field `_gl_verify_error_if_negative' Alan Mackenzie
2012-02-12 21:31 ` Paul Eggert
2012-02-13 13:07 ` Alan Mackenzie
2012-02-13 16:57 ` Paul Eggert
2012-02-13 20:34 ` Alan Mackenzie
2012-02-13 20:50 ` Paul Eggert
2012-02-13 22:41 ` Alan Mackenzie
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.