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

Package: emacs;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator 
Date: Sun, 17 Feb 2013 12:48:17 +0100
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):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Sun, 17 Feb 2013 14:19:19 +0100
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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Sun, 17 Feb 2013 17:10:35 +0100
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):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Sun, 17 Feb 2013 17:16:00 +0100
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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Sun, 17 Feb 2013 17:15:36 +0100
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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Sun, 17 Feb 2013 17:31:37 +0100
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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Fri, 1 Mar 2013 20:13:32 +0100
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):

From: Glenn Morris <rgm <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 13734 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Fri, 01 Mar 2013 14:45:33 -0500
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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13734 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue or
	a function designator
Date: Fri, 1 Mar 2013 21:06:30 +0100
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: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue
	or	a function designator
Date: Fri, 01 Mar 2013 22:27:38 +0200
> 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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue
	or	a function designator
Date: Sat, 2 Mar 2013 00:25:41 +0100
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):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: rgm <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, 13734-done <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue
	or	a function designator
Date: Sat, 02 Mar 2013 08:58:47 +0100
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: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 13734 <at> debbugs.gnu.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an lvalue
	or	a function designator
Date: Sat, 02 Mar 2013 10:24:18 +0200
> 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):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13734 <at> debbugs.gnu.org, Peter_Dyballa <at> Freenet.DE, schwab <at> linux-m68k.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an
	lvalue	or	a function designator
Date: Sat, 02 Mar 2013 10:39:57 +0200
> 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):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter_Dyballa <at> Freenet.DE
Cc: 13734 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an
	lvalue	or	a function designator
Date: Sat, 02 Mar 2013 11:06:03 +0200
> 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):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13734 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an
	lvalue	or	a function designator
Date: Sat, 2 Mar 2013 17:26:21 +0100
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: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 13734 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#13734: 24.3.50;
	../src/lisp.h:2485:10: error: address expression must be an
	lvalue	or	a function designator
Date: Sat, 02 Mar 2013 19:01:13 +0200
> 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.