* 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.