bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Andreas Schwab]

Peter Dyballa <Peter_Dyballa@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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.

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Andreas Schwab]

Peter Dyballa <Peter_Dyballa@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Glenn Morris]

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.

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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?

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Eli Zaretskii]

> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Fri, 1 Mar 2013 21:06:30 +0100
> Cc: 13734@debbugs.gnu.org, Andreas Schwab <schwab@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.)

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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.

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Andreas Schwab]

Fixed in emacs-24 branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Eli Zaretskii]

> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Sat, 2 Mar 2013 00:25:41 +0100
> Cc: rgm@gnu.org,
>  13734@debbugs.gnu.org,
>  schwab@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.

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Eli Zaretskii]

> Date: Sat, 02 Mar 2013 10:24:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: schwab@linux-m68k.org, 13734@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@cs.ucla.edu-20110429075443-o3bf5tg5tha3yvrx

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Eli Zaretskii]

> Date: Sat, 02 Mar 2013 10:24:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: schwab@linux-m68k.org, 13734@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.

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

Am 02.03.2013 um 10:06 schrieb Eli Zaretskii:

>> Date: Sat, 02 Mar 2013 10:24:18 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: schwab@linux-m68k.org, 13734@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@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

bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Eli Zaretskii]

> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Sat, 2 Mar 2013 17:26:21 +0100
> Cc: schwab@linux-m68k.org,
>  13734@debbugs.gnu.org
> 
> Your fix was fetched by bzr:
> 
> 	revno: 111912
> 	behebt den Fehler: http://debbugs.gnu.org/13734
> 	committer: Eli Zaretskii <eliz@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#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator

[Peter Dyballa]

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