GNU bug report logs -
#13734
24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
Previous Next
Reported by: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Date: Sun, 17 Feb 2013 11:54:01 UTC
Severity: minor
Tags: moreinfo
Found in version 24.3.50
Done: Andreas Schwab <schwab <at> linux-m68k.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13734 in the body.
You can then email your comments to 13734 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sun, 17 Feb 2013 11:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 17 Feb 2013 11:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello!
This statement does not seems to be correct C code:
return & XVECTOR (array)->contents[idx];
Now at revno: 111817
--
Greetings
Pete
~ o
~_\\_/\
~ O O
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sun, 17 Feb 2013 13:21:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Peter Dyballa <Peter_Dyballa <at> Freenet.DE> writes:
> This statement does not seems to be correct C code:
>
> return & XVECTOR (array)->contents[idx];
How so? XVECTOR (array)->contents[idx] is definitely an lvalue.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sun, 17 Feb 2013 16:15:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Am 17.02.2013 um 14:19 schrieb Andreas Schwab:
>> return & XVECTOR (array)->contents[idx];
>
> How so? XVECTOR (array)->contents[idx] is definitely an lvalue.
Can it be that GCC 4.2 and Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn) both mean the "return" operator?
At least me, I wouldn't bitwise AND an operator and an lvalue…
--
Greetings
Pete
The human brain operates at only 10% of its capacity. The rest is overhead for the operating system.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sun, 17 Feb 2013 16:17:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Peter Dyballa <Peter_Dyballa <at> Freenet.DE> writes:
> Can it be that GCC 4.2 and Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn) both mean the "return" operator?
return is not an operator.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sun, 17 Feb 2013 16:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Am 17.02.2013 um 14:19 schrieb Andreas Schwab:
>> return & XVECTOR (array)->contents[idx];
>
> How so? XVECTOR (array)->contents[idx] is definitely an lvalue.
GCC 4.7.2 tells me more precisely:
../src/lisp.h:2485:10: error: lvalue required as unary ‘&’ operand
--
Mit friedvollen Grüßen
Pete
Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration.
– Donald Knuth
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sun, 17 Feb 2013 16:36:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Am 17.02.2013 um 17:16 schrieb Andreas Schwab:
> return is not an operator.
Sorry! I meant "operand" as in "me & 2;".
--
Mit friedvollen Grüßen
Pete
The future will be much better tomorrow.
– George W. Bush
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Fri, 01 Mar 2013 19:20:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 13734 <at> debbugs.gnu.org (full text, mbox):
On PPC Tiger, Mac OS X 10.4.11, with powerpc-apple-darwin8-gcc-4.0.1
(GCC) 4.0.1 (Apple Computer, Inc. build 5370), now at revno: 111907,
src/emacs compiles, no problem with src/lisp.h in lwlib comes up:
cd ../lwlib; make \
CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-common
-Os -mcpu=7450 -mtune=7450 -maltivec -faltivec -mabi=altivec'
MAKE='make'
gcc -std=gnu99 -c -I/sw/include -I/usr/X11R6/include -I/sw/include -
I/sw/include/freetype2 -I/usr/X11/include -I/usr/X11R6/include
`echo | sed 's/ -Wwrite-strings//'` -g -ggdb3 -H -pipe -fPIC -fno-
common -Os -mcpu=7450 -mtune=7450 -maltivec -faltivec -mabi=altivec -
Demacs -I../src -I.../emacs-24.3.50/lwlib -I.../emacs-24.3.50/
lwlib/../src -I../lib -I.../emacs-24.3.50/lwlib/../lib lwlib.c
. ../src/config.h
.. ../src/conf_post.h
... ../lib/alloca.h
... ../lib/string.h
.... /usr/include/string.h
..... /usr/include/_types.h
...... /usr/include/sys/_types.h
....... /usr/include/sys/cdefs.h
....... /usr/include/machine/_types.h
........ /usr/include/ppc/_types.h
.... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
... ../lib/stdlib.h
.... /usr/include/stdlib.h
..... /usr/include/sys/wait.h
...... /usr/include/sys/signal.h
....... /usr/include/sys/appleapiopts.h
....... /usr/include/machine/signal.h
........ /usr/include/ppc/signal.h
...... /usr/include/sys/resource.h
...... /usr/include/machine/endian.h
....... /usr/include/ppc/endian.h
........ /usr/include/sys/_endian.h
......... ../lib/stdint.h
.......... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h
.......... /usr/include/sys/types.h
........... /usr/include/machine/types.h
............ /usr/include/ppc/types.h
........... /usr/include/machine/endian.h
.......... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h
........... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/
syslimits.h
............ /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h
............. /usr/include/limits.h
.............. /usr/include/machine/limits.h
............... /usr/include/ppc/limits.h
................ /usr/include/ppc/_limits.h
.............. /usr/include/sys/syslimits.h
.......... ../lib/inttypes.h
........... /usr/include/inttypes.h
............ ../lib/stdint.h
......... /usr/include/libkern/OSByteOrder.h
.......... /usr/include/libkern/ppc/OSByteOrder.h
.... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
. /usr/include/setjmp.h
.. /usr/include/machine/setjmp.h
... /usr/include/ppc/setjmp.h
. ../src/lisp.h
.. ../lib/stdalign.h
... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdarg.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdbool.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/float.h
.. ../lib/inttypes.h
... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h
.. ../lib/intprops.h
... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h
.. ../src/globals.h
. ../lib/c-strcase.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
. ../lib/stdio.h
.. /usr/include/stdio.h
.. /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
. lwlib-int.h
.. lwlib.h
... /usr/X11R6/include/X11/Intrinsic.h
.... /usr/X11R6/include/X11/Xlib.h
..... /usr/X11R6/include/X11/X.h
..... /usr/X11R6/include/X11/Xfuncproto.h
..... /usr/X11R6/include/X11/Xosdefs.h
..... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
.... /usr/X11R6/include/X11/Xutil.h
.... /usr/X11R6/include/X11/Xresource.h
.... /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stddef.h
.... /usr/X11R6/include/X11/Core.h
.... /usr/X11R6/include/X11/Composite.h
.... /usr/X11R6/include/X11/Constraint.h
.... /usr/X11R6/include/X11/Object.h
.... /usr/X11R6/include/X11/RectObj.h
. lwlib-utils.h
. /usr/X11R6/include/X11/StringDefs.h
. lwlib-Xlw.h
. /sw/include/X11/Xaw3d/Paned.h
.. /usr/X11R6/include/X11/Xmu/Converters.h
. lwlib-Xaw.h
Since the original C statement has not changed, something else must
have changed…
I'll boot into PPC Leopard, Mac OS X 10.5.8, and see what is
happening there. And finally trying GCC 4.0.1.
--
Mit friedvollen Grüßen
Pete
Never be led astray onto the path of virtue
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Fri, 01 Mar 2013 19:48:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Peter Dyballa wrote:
> On PPC Tiger, Mac OS X 10.4.11, with powerpc-apple-darwin8-gcc-4.0.1
> (GCC) 4.0.1 (Apple Computer, Inc. build 5370), now at revno: 111907,
> src/emacs compiles, no problem with src/lisp.h in lwlib comes up:
>
> cd ../lwlib; make \ CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H
> -pipe -fPIC -fno-common -Os -mcpu=7450 -mtune=7450 -maltivec -faltivec
> -mabi=altivec' MAKE='make' gcc -std=gnu99 -c -I/sw/include
> -I/usr/X11R6/include -I/sw/include - I/sw/include/freetype2
[...]
> Since the original C statement has not changed, something else must
> have changed…
>
> I'll boot into PPC Leopard, Mac OS X 10.5.8, and see what is happening
> there. And finally trying GCC 4.0.1.
As a general comment, you seem to have multiple versions of libraries
and compilers on your system(s), and to like using lots of compiler
flags. You have lots of bug reports about various weird things on
different flavours of Mac OS X. There doesn't seem to be anyone
interested in debugging most of them, so I would suggest just finding a
single simple build configuration that works for you, and sticking with
it, rather than trying to explore every possible build configuration.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Fri, 01 Mar 2013 20:12:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Am 01.03.2013 um 20:45 schrieb Glenn Morris:
> You have lots of bug reports about various weird things on
> different flavours of Mac OS X.
Three old versions of Mac OS X (10.4.11, 10.5.8, 10.6.8) on two different hardware platforms.
The cause of the error in src/lisp.h seems to be related to the configure option --with-wide-int. When I am not using it, lwlib can be compiled, when I am using it, the reported error occurs.
--
Greetings
Pete
Who the fsck is "General Failure," and why is he reading my disk?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Fri, 01 Mar 2013 20:30:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 13734 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Fri, 1 Mar 2013 21:06:30 +0100
> Cc: 13734 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
>
> The cause of the error in src/lisp.h seems to be related to the configure option --with-wide-int. When I am not using it, lwlib can be compiled, when I am using it, the reported error occurs.
Can you post a cpp-preprocessed code of that line in lisp.h, when
configured --with-wide-int, from the compilation of a C source which
triggers the error (lwlib.c, I think)?
(In case you didn't know, the easiest way of producing such
preprocessed code is to replace "-c" with "-E" in the compilation
command line, and change "-o lwlib.o" to "-o lwlib.ii" or some such,
to avoid overwriting the object file.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Fri, 01 Mar 2013 23:30:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Am 01.03.2013 um 21:27 schrieb Eli Zaretskii:
> Can you post a cpp-preprocessed code of that line in lisp.h, when
> configured --with-wide-int, from the compilation of a C source which
> triggers the error (lwlib.c, I think)?
I can't! In the middle of C pre-processing this happens:
In file included from lwlib.c:24:
../src/lisp.h:3841:52: error: macro "EQ" requires 2 arguments, but only 1 given
I have the output from the configuration with 32-bit libraries, and I can also produce the output when configured for 64-bit libraries…
The original GCC invocation when configured --with-wide-int was:
gcc-4.2 -std=gnu99 -c -I/sw/include -I/usr/X11/include -I/sw/include -I/sw/include/freetype2 -I/usr/X11/include -I/usr/X11R6/include `echo | sed 's/ -Wwrite-strings//'` -g3 -H -pipe -fPIC -fno-common -Os -march=core2 -mtune=core2 -m32 -fomit-frame-pointer -msse4.2 -Demacs -I../src -I.../emacs-24.3.50/lwlib -I.../emacs-24.3.50/lwlib/../src -I../lib -I.../emacs-24.3.50/lwlib/../lib lwlib.c
which I changed to
gcc-4.2 -std=gnu99 -E -I/sw/include -I/usr/X11/include -I/sw/include -I/sw/include/freetype2 -I/usr/X11/include -I/usr/X11R6/include `echo | sed 's/ -Wwrite-strings//'` -g3 -H -pipe -fPIC -fno-common -Os -march=core2 -mtune=core2 -m32 -fomit-frame-pointer -msse4.2 -Demacs -I../src -I.../emacs-24.3.50/lwlib -I.../emacs-24.3.50/lwlib/../src -I../lib -I.../emacs-24.3.50/lwlib/../lib lwlib.c -o lwlib-wide.ii
being invoked on the command line. I then removed the -H flag and also -o lwlib-wide.ii because there must be some output until the error occurs, at least. And it did! So I finally invoked
gcc-4.2 -std=gnu99 -E -I/sw/include -I/usr/X11/include -I/sw/include -I/sw/include/freetype2 -I/usr/X11/include -I/usr/X11R6/include `echo | sed 's/ -Wwrite-strings//'` -g3 -pipe -fPIC -fno-common -Os -march=core2 -mtune=core2 -m32 -fomit-frame-pointer -msse4.2 -Demacs -I../src -I.../emacs-24.3.50/lwlib -I.../emacs-24.3.50/lwlib/../src -I../lib -I.../emacs-24.3.50/lwlib/../lib lwlib.c > lwlib-wide.ii
'wc lwlib-wide.ii' delivers
23447 55614 560933 lwlib-wide.ii
This is the pre-processed function:
static __attribute__ ((__unused__)) Lisp_Object *
aref_addr (Lisp_Object array, ptrdiff_t idx)
{
return & (((void) (0 && ((((enum Lisp_Type) ((EMACS_UINT) ((array)) >> VALBITS)) == Lisp_Vectorlike)))), (struct Lisp_Vector *) ((gl_uintptr_t) (((array) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->contents[idx];
}
And this is – presumingly – the function with EQ with only one argument:
static __attribute__ ((__unused__)) int
functionp (Lisp_Object object)
{
if ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Symbol) && !((Ffboundp (object)) == (Qnil)))
{
object = Findirect_function (object, Qt);
if ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons) && (((0 + (((((void) (0 && ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons)))), (struct Lisp_Cons *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->car)))) == (Qautoload)))
{
int i;
for (i = 0; i < 4 && (((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons); i++)
object = (0 + (((((void) (0 && ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons)))), (struct Lisp_Cons *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->u.cdr)));
return ! ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons) && !EQ, Qnil));
}
}
if (((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Vectorlike) && ((((struct vectorlike_header *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->size & ((((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) - ((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) / 2) | PVEC_TYPE_MASK)) == ((((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) - ((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) / 2) | ((PVEC_SUBR) << PSEUDOVECTOR_AREA_BITS)))))
return (((void) (0 && (((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Vectorlike) && ((((struct vectorlike_header *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->size & ((((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) - ((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) / 2) | PVEC_TYPE_MASK)) == ((((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) - ((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) / 2) | ((PVEC_SUBR) << PSEUDOVECTOR_AREA_BITS))))))), (struct Lisp_Subr *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->max_args != UNEVALLED;
else if (((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Vectorlike) && ((((struct vectorlike_header *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->size & ((((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) - ((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) / 2) | PVEC_TYPE_MASK)) == ((((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) - ((1) ? ~ ((1) ? (- ((0) + 1) << ((32) ? (32) - 1 : 0)) : (0)) : ((((0) + 1) << ((32) ? (32) - 1 - (1) : 0)) - 1) * 2 + 1) / 2) | ((PVEC_COMPILED) << PSEUDOVECTOR_AREA_BITS)))))
return 1;
else if ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons))
{
Lisp_Object car = (0 + (((((void) (0 && ((((enum Lisp_Type) ((EMACS_UINT) ((object)) >> VALBITS)) == Lisp_Cons)))), (struct Lisp_Cons *) ((gl_uintptr_t) (((object) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->car)));
return ((car) == (Qlambda)) || ((car) == (Qclosure));
}
else
return 0;
}
I wrote "presumingly" because GNU Emacs did not perform forward-sexp on the opening { starting the function definition.
--
Greetings
Pete
Basic, n.:
A programming language. Related to certain social diseases in that those who have it will not admit it in polite company.
Reply sent
to
Andreas Schwab <schwab <at> linux-m68k.org>
:
You have taken responsibility.
(Sat, 02 Mar 2013 07:59:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
:
bug acknowledged by developer.
(Sat, 02 Mar 2013 07:59:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 13734-done <at> debbugs.gnu.org (full text, mbox):
Fixed in emacs-24 branch.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sat, 02 Mar 2013 08:25:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 13734 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sat, 2 Mar 2013 00:25:41 +0100
> Cc: rgm <at> gnu.org,
> 13734 <at> debbugs.gnu.org,
> schwab <at> linux-m68k.org
>
>
> Am 01.03.2013 um 21:27 schrieb Eli Zaretskii:
>
> > Can you post a cpp-preprocessed code of that line in lisp.h, when
> > configured --with-wide-int, from the compilation of a C source which
> > triggers the error (lwlib.c, I think)?
>
> I can't! In the middle of C pre-processing this happens:
>
> In file included from lwlib.c:24:
> ../src/lisp.h:3841:52: error: macro "EQ" requires 2 arguments, but only 1 given
> [...]
> This is the pre-processed function:
>
> static __attribute__ ((__unused__)) Lisp_Object *
> aref_addr (Lisp_Object array, ptrdiff_t idx)
> {
> return & (((void) (0 && ((((enum Lisp_Type) ((EMACS_UINT) ((array)) >> VALBITS)) == Lisp_Vectorlike)))), (struct Lisp_Vector *) ((gl_uintptr_t) (((array) & (9223372036854775807LL >> (3 - 1)))) | DATA_SEG_BITS)))->contents[idx];
> }
Thanks, this gave the crucial clue. (Your configuration uses a setup
where USE_LSB_TAG is not used, which I guess is something no one tried
in a long time.) There was a mismatch of parentheses in the
definition of XPNTR in that branch, which I believe caused these
problems. Please try the latest trunk, I hope I fixed this in
revision 111912.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sat, 02 Mar 2013 08:41:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 13734 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 02 Mar 2013 10:24:18 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: schwab <at> linux-m68k.org, 13734 <at> debbugs.gnu.org
>
> Your configuration uses a setup where USE_LSB_TAG is not used, which
> I guess is something no one tried in a long time.
More precisely, since this revision:
104021.1.18 eggert <at> cs.ucla.edu-20110429075443-o3bf5tg5tha3yvrx
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sat, 02 Mar 2013 09:07:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 13734 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 02 Mar 2013 10:24:18 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: schwab <at> linux-m68k.org, 13734 <at> debbugs.gnu.org
>
> Thanks, this gave the crucial clue. (Your configuration uses a setup
> where USE_LSB_TAG is not used, which I guess is something no one tried
> in a long time.) There was a mismatch of parentheses in the
> definition of XPNTR in that branch, which I believe caused these
> problems. Please try the latest trunk, I hope I fixed this in
> revision 111912.
This was meanwhile fixed on the release branch by Andreas, so I
reverted the trunk commit. Please wait until the branch is merged
with the trunk, or copy the fix from the branch (revno 111311)
manually.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sat, 02 Mar 2013 16:31:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 13734 <at> debbugs.gnu.org (full text, mbox):
Am 02.03.2013 um 10:06 schrieb Eli Zaretskii:
>> Date: Sat, 02 Mar 2013 10:24:18 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: schwab <at> linux-m68k.org, 13734 <at> debbugs.gnu.org
>>
>> Thanks, this gave the crucial clue. (Your configuration uses a setup
>> where USE_LSB_TAG is not used, which I guess is something no one tried
>> in a long time.) There was a mismatch of parentheses in the
>> definition of XPNTR in that branch, which I believe caused these
>> problems. Please try the latest trunk, I hope I fixed this in
>> revision 111912.
>
> This was meanwhile fixed on the release branch by Andreas, so I
> reverted the trunk commit. Please wait until the branch is merged
> with the trunk, or copy the fix from the branch (revno 111311)
> manually.
I updated to revno: 111915, src/lisp.h has a date from Thursday and 'bzr status' tells me that all is up-to-date. But GCC 4.2 still sees:
In file included from lwlib.c:24:
../src/lisp.h: In function ‘aref_addr’:
../src/lisp.h:2485: error: lvalue required as unary ‘&’ operand
../src/lisp.h:2485: error: expected ‘;’ before ‘)’ token
../src/lisp.h:2485: error: expected statement before ‘)’ token
../src/lisp.h:2485: error: expected expression before ‘->’ token
Your fix was fetched by bzr:
revno: 111912
behebt den Fehler: http://debbugs.gnu.org/13734
committer: Eli Zaretskii <eliz <at> gnu.org>
branch nick: trunk
timestamp: Sat 2013-03-02 10:19:45 +0200
message:
Fix bug #13734 with errors in lisp.h macro expansion.
src/lisp.h (XPNTR) [!USE_LSB_TAG]: Fix parentheses nesting.
…but not applied? See the file's date from thursday:
-rw-r--r-- 1 pete admin 137928 28. Feb 23:27 src/lisp.h
--
Greetings
Pete
Work is the curse of the drinking class.
– Oscar Wilde
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13734
; Package
emacs
.
(Sat, 02 Mar 2013 17:02:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 13734 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Sat, 2 Mar 2013 17:26:21 +0100
> Cc: schwab <at> linux-m68k.org,
> 13734 <at> debbugs.gnu.org
>
> Your fix was fetched by bzr:
>
> revno: 111912
> behebt den Fehler: http://debbugs.gnu.org/13734
> committer: Eli Zaretskii <eliz <at> gnu.org>
> branch nick: trunk
> timestamp: Sat 2013-03-02 10:19:45 +0200
> message:
> Fix bug #13734 with errors in lisp.h macro expansion.
>
> src/lisp.h (XPNTR) [!USE_LSB_TAG]: Fix parentheses nesting.
>
> …but not applied? See the file's date from thursday:
>
> -rw-r--r-- 1 pete admin 137928 28. Feb 23:27 src/lisp.h
See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13734#49.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 31 Mar 2013 11:24:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 364 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.