* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
@ 2013-02-17 11:48 Peter Dyballa
2013-02-17 13:19 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Peter Dyballa @ 2013-02-17 11:48 UTC (permalink / raw)
To: 13734
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-02-17 11:48 bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator Peter Dyballa
@ 2013-02-17 13:19 ` Andreas Schwab
2013-02-17 16:10 ` Peter Dyballa
2013-02-17 16:15 ` Peter Dyballa
0 siblings, 2 replies; 17+ messages in thread
From: Andreas Schwab @ 2013-02-17 13:19 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 13734
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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-02-17 13:19 ` Andreas Schwab
@ 2013-02-17 16:10 ` Peter Dyballa
2013-02-17 16:16 ` Andreas Schwab
2013-02-17 16:15 ` Peter Dyballa
1 sibling, 1 reply; 17+ messages in thread
From: Peter Dyballa @ 2013-02-17 16:10 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 13734
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-02-17 13:19 ` Andreas Schwab
2013-02-17 16:10 ` Peter Dyballa
@ 2013-02-17 16:15 ` Peter Dyballa
1 sibling, 0 replies; 17+ messages in thread
From: Peter Dyballa @ 2013-02-17 16:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 13734
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-02-17 16:10 ` Peter Dyballa
@ 2013-02-17 16:16 ` Andreas Schwab
2013-02-17 16:31 ` Peter Dyballa
2013-03-01 19:13 ` Peter Dyballa
0 siblings, 2 replies; 17+ messages in thread
From: Andreas Schwab @ 2013-02-17 16:16 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 13734
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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-02-17 16:16 ` Andreas Schwab
@ 2013-02-17 16:31 ` Peter Dyballa
2013-03-01 19:13 ` Peter Dyballa
1 sibling, 0 replies; 17+ messages in thread
From: Peter Dyballa @ 2013-02-17 16:31 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 13734
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-02-17 16:16 ` Andreas Schwab
2013-02-17 16:31 ` Peter Dyballa
@ 2013-03-01 19:13 ` Peter Dyballa
2013-03-01 19:45 ` Glenn Morris
1 sibling, 1 reply; 17+ messages in thread
From: Peter Dyballa @ 2013-03-01 19:13 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 13734
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-01 19:13 ` Peter Dyballa
@ 2013-03-01 19:45 ` Glenn Morris
2013-03-01 20:06 ` Peter Dyballa
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2013-03-01 19:45 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 13734, Andreas Schwab
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-01 19:45 ` Glenn Morris
@ 2013-03-01 20:06 ` Peter Dyballa
2013-03-01 20:27 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Peter Dyballa @ 2013-03-01 20:06 UTC (permalink / raw)
To: Glenn Morris; +Cc: 13734, Andreas Schwab
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-01 20:06 ` Peter Dyballa
@ 2013-03-01 20:27 ` Eli Zaretskii
2013-03-01 23:25 ` Peter Dyballa
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-03-01 20:27 UTC (permalink / raw)
To: Peter Dyballa; +Cc: schwab, 13734
> 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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-01 20:27 ` Eli Zaretskii
@ 2013-03-01 23:25 ` Peter Dyballa
2013-03-02 7:58 ` Andreas Schwab
2013-03-02 8:24 ` Eli Zaretskii
0 siblings, 2 replies; 17+ messages in thread
From: Peter Dyballa @ 2013-03-01 23:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: schwab, 13734
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-01 23:25 ` Peter Dyballa
@ 2013-03-02 7:58 ` Andreas Schwab
2013-03-02 8:24 ` Eli Zaretskii
1 sibling, 0 replies; 17+ messages in thread
From: Andreas Schwab @ 2013-03-02 7:58 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 13734-done
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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-01 23:25 ` Peter Dyballa
2013-03-02 7:58 ` Andreas Schwab
@ 2013-03-02 8:24 ` Eli Zaretskii
2013-03-02 8:39 ` Eli Zaretskii
2013-03-02 9:06 ` Eli Zaretskii
1 sibling, 2 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-03-02 8:24 UTC (permalink / raw)
To: Peter Dyballa; +Cc: schwab, 13734
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-02 8:24 ` Eli Zaretskii
@ 2013-03-02 8:39 ` Eli Zaretskii
2013-03-02 9:06 ` Eli Zaretskii
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-03-02 8:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13734, Peter_Dyballa, schwab
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-02 8:24 ` Eli Zaretskii
2013-03-02 8:39 ` Eli Zaretskii
@ 2013-03-02 9:06 ` Eli Zaretskii
2013-03-02 16:26 ` Peter Dyballa
1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-03-02 9:06 UTC (permalink / raw)
To: Peter_Dyballa; +Cc: 13734, schwab
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-02 9:06 ` Eli Zaretskii
@ 2013-03-02 16:26 ` Peter Dyballa
2013-03-02 17:01 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Peter Dyballa @ 2013-03-02 16:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13734, schwab
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator
2013-03-02 16:26 ` Peter Dyballa
@ 2013-03-02 17:01 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-03-02 17:01 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 13734, schwab
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-03-02 17:01 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-17 11:48 bug#13734: 24.3.50; ../src/lisp.h:2485:10: error: address expression must be an lvalue or a function designator Peter Dyballa
2013-02-17 13:19 ` Andreas Schwab
2013-02-17 16:10 ` Peter Dyballa
2013-02-17 16:16 ` Andreas Schwab
2013-02-17 16:31 ` Peter Dyballa
2013-03-01 19:13 ` Peter Dyballa
2013-03-01 19:45 ` Glenn Morris
2013-03-01 20:06 ` Peter Dyballa
2013-03-01 20:27 ` Eli Zaretskii
2013-03-01 23:25 ` Peter Dyballa
2013-03-02 7:58 ` Andreas Schwab
2013-03-02 8:24 ` Eli Zaretskii
2013-03-02 8:39 ` Eli Zaretskii
2013-03-02 9:06 ` Eli Zaretskii
2013-03-02 16:26 ` Peter Dyballa
2013-03-02 17:01 ` Eli Zaretskii
2013-02-17 16:15 ` Peter Dyballa
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.