3:33 p.m.
Hi,
with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I get
[...]
checking for working alloca.h... no
checking for alloca... no
Defining C_ALLOCA
checking whether alloca needs Cray hooks... no
checking stack direction for C alloca... -1
Defining STACK_DIRECTION = -1
xemacs will be linked with "alloca.o"
[...]
The reason is that ccc won't find alloca when linking if passed
"-std1", which is added by xemacs configure. (ccc picks up gcc's
alloca.h, but the alloca.h check wants to link, too, so it fails.)
Then when building one gets lots of warnings:
ccc -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src
-I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1
/usr/local/src/xemacs-21.2-10.12/lib-src/wakeup.c -ldb -lgpm -lncurses -L/usr/lib -lesd
-laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o wakeup
cc: Warning: /usr/include/alloca.h, line 33: In this declaration, the type of the function
"alloca", declared in a system header file, is not compatible with the earlier
declaration of "alloca" at line number 43 in file ../src/config.h.
(funcredeclext1)
extern __ptr_t alloca __P ((size_t __size));
---------------^
(__ptr_t is a #define for void *, while config.h declares the return
value as char *)
Finally, it fails:
ccc -c -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src
-I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1
/usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c
cc: Error: /usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c, line 191: In this
declaration, the type of "alloca" is not compatible with the type of a previous
declaration of "alloca" at line number 43 in file ../src/config.h. (notcompat)
alloca (size)
^
because alloca.c declares alloca as returning "pointer", which is
typedefed to void *.
Now I wonder how to fix this best; one could for example:
* remove -std1 from the ccc flags
* use something like
#if defined(__DECC) && defined(__linux__)
# include <machine/builtins.h>
# define alloca __ALLOCA
#endif
which also works with -std1
* consistentialize xemacs' declarations; regex.c also wants to declare
alloca as returning char *.
And if anybody feels a bit bored, here are a few interesting warnings:
cc: Warning: miscplay.c, line 384: In this statement, the expression
"*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char
...)(src++)))/2)" modifies the variable "src" more than once without an
intervening sequence point. This behavior is undefined. (undefvarmod)
*dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
----^
cc: Warning: miscplay.c, line 405: In this statement, the expression
"*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char
...)(src++)))/2)^0X0000000000000080" modifies the variable "src" more than
once without an intervening sequence point. This behavior is undefined. (undefvarmod)
*dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
----^
cc: Warning: miscplay.c, line 496: In this statement, the expression
"*p++=ulaw_dsp[*p]" modifies "p", and fetches its value in a
computation that is not used to produce the modified value without an intervening sequence
point. This behavior is undefined. (undefvarfetch)
*p++ = ulaw_dsp[*p];
----^
cc: Warning: miscplay.c, line 570: In this statement, the expression
"*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies
"p", and fetches its value in a computation that is not used to produce the
modified value without an intervening sequence point. This behavior is undefined.
(undefvarfetch)
*p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
----^
cc: Warning: miscplay.c, line 570: In this statement, the expression
"*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies
"p", and fetches its value in a computation that is not used to produce the
modified value without an intervening sequence point. This behavior is undefined.
(undefvarfetch)
*p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
----^
cc: Warning: regex.c, line 5627: This statement uses the type "union declared without
a tag" to reference the same storage location as the statement at line number 5627 in
file regex.c, which uses the type "long". This does not conform to the ANSI
aliasing rules. (badansialias)
POP_FAILURE_POINT (d, p,
----------^
cc: Warning: regex.c, line 5312: This statement uses the type "union declared without
a tag" to reference the same storage location as the statement at line number 5312 in
file regex.c, which uses the type "long". This does not conform to the ANSI
aliasing rules. (badansialias)
POP_FAILURE_POINT (sdummy, pdummy,
------------^
Falk
3:45 a.m.
Grüße.
I would like to debug your problem, so as always, I ask for access to
your machine. I can send my ssh public key.
>>>> "Falk" == Falk Hueffner
<falk.hueffner(a)student.uni-tuebingen.de> writes:
Falk> Hi,
Falk> with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I get
Falk> [...]
Falk> checking for working alloca.h... no
Falk> checking for alloca... no
Falk> Defining C_ALLOCA
Falk> checking whether alloca needs Cray hooks... no
Falk> checking stack direction for C alloca... -1
Falk> Defining STACK_DIRECTION = -1
Falk> xemacs will be linked with "alloca.o"
Falk> [...]
Falk> The reason is that ccc won't find alloca when linking if passed
Falk> "-std1", which is added by xemacs configure. (ccc picks up gcc's
Falk> alloca.h, but the alloca.h check wants to link, too, so it fails.)
I was the one who added that '-std1', which works fine on Tru64 with
cc (cc)
Digital UNIX Compiler Driver 3.11
DEC C V5.8-009 on Digital UNIX V4.0 (Rev. 1091)
Falk> Then when building one gets lots of warnings:
Falk> ccc -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src
-I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1
/usr/local/src/xemacs-21.2-10.12/lib-src/wakeup.c -ldb -lgpm -lncurses -L/usr/lib -lesd
-laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o wakeup
Falk> cc: Warning: /usr/include/alloca.h, line 33: In this declaration, the type of the
function "alloca", declared in a system header file, is not compatible with the
earlier declaration of "alloca" at line number 43 in file ../src/config.h.
(funcredeclext1)
Falk> extern __ptr_t alloca __P ((size_t __size));
Falk> ---------------^
It seems C_ALLOCA could use some work. For starters, it should be ANSIfied.
Falk> (__ptr_t is a #define for void *, while config.h declares the return
Falk> value as char *)
Falk> Finally, it fails:
Falk> ccc -c -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src
-I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1
/usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c
Falk> cc: Error: /usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c, line 191: In
this declaration, the type of "alloca" is not compatible with the type of a
previous declaration of "alloca" at line number 43 in file ../src/config.h.
(notcompat)
Falk> alloca (size)
Falk> ^
Falk> because alloca.c declares alloca as returning "pointer", which is
Falk> typedefed to void *.
Falk> Now I wonder how to fix this best; one could for example:
Falk> * remove -std1 from the ccc flags
No.
Falk> * use something like
Falk> #if defined(__DECC) && defined(__linux__)
Falk> # include <machine/builtins.h>
Falk> # define alloca __ALLOCA
Falk> #endif
Falk> which also works with -std1
I would prefer a configure test for __ALLOCA, and add some logic to
use __ALLOCA the top of src/config.h.in.
Falk> * consistentialize xemacs' declarations; regex.c also wants to declare
Falk> alloca as returning char *.
Yes. But it's hard for me to make these kinds of changes without
access to your system.
Falk> And if anybody feels a bit bored, here are a few interesting warnings:
These are fantastic warnings. What a great compiler! I'll fix miscplay.c.
Falk> cc: Warning: miscplay.c, line 384: In this statement, the expression
"*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char
...)(src++)))/2)" modifies the variable "src" more than once without an
intervening sequence point. This behavior is undefined. (undefvarmod)
Falk> *dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
Falk> ----^
Falk> cc: Warning: miscplay.c, line 405: In this statement, the expression
"*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char
...)(src++)))/2)^0X0000000000000080" modifies the variable "src" more than
once without an intervening sequence point. This behavior is undefined. (undefvarmod)
Falk> *dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
Falk> ----^
Falk> cc: Warning: miscplay.c, line 496: In this statement, the expression
"*p++=ulaw_dsp[*p]" modifies "p", and fetches its value in a
computation that is not used to produce the modified value without an intervening sequence
point. This behavior is undefined. (undefvarfetch)
Falk> *p++ = ulaw_dsp[*p];
Falk> ----^
Falk> cc: Warning: miscplay.c, line 570: In this statement, the expression
"*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies
"p", and fetches its value in a computation that is not used to produce the
modified value without an intervening sequence point. This behavior is undefined.
(undefvarfetch)
Falk> *p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
Falk> ----^
Falk> cc: Warning: miscplay.c, line 570: In this statement, the expression
"*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies
"p", and fetches its value in a computation that is not used to produce the
modified value without an intervening sequence point. This behavior is undefined.
(undefvarfetch)
Falk> *p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
Falk> ----^
I'd like to fix the next two, but I think I'd like the help of your
wonderful compiler to track down the stuff in the preprocessor magic.
Or you could try doing this if you'd like to help with the hacking.
Falk> cc: Warning: regex.c, line 5627: This statement uses the type "union
declared without a tag" to reference the same storage location as the statement at
line number 5627 in file regex.c, which uses the type "long". This does not
conform to the ANSI aliasing rules. (badansialias)
Falk> POP_FAILURE_POINT (d, p,
Falk> ----------^
Falk> cc: Warning: regex.c, line 5312: This statement uses the type "union
declared without a tag" to reference the same storage location as the statement at
line number 5312 in file regex.c, which uses the type "long". This does not
conform to the ANSI aliasing rules. (badansialias)
Falk> POP_FAILURE_POINT (sdummy, pdummy,
Falk> ------------^
Martin
11:02 a.m.
On Tue, 17 Oct 2000, Martin Buchholz wrote:
I would like to debug your problem, so as always, I ask for access
to
your machine. I can send my ssh public key.
Unfortunately it is a dial-up machine, so this isn't really possible...
Falk> with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I
get
Falk> [...]
Falk> checking for working alloca.h... no
Falk> checking for alloca... no
Falk> Defining C_ALLOCA
Falk> checking whether alloca needs Cray hooks... no
Falk> checking stack direction for C alloca... -1
Falk> Defining STACK_DIRECTION = -1
Falk> xemacs will be linked with "alloca.o"
Falk> [...]
Falk> The reason is that ccc won't find alloca when linking if passed
Falk> "-std1", which is added by xemacs configure. (ccc picks up gcc's
Falk> alloca.h, but the alloca.h check wants to link, too, so it fails.)
I was the one who added that '-std1', which works fine on Tru64 with
cc (cc)
Digital UNIX Compiler Driver 3.11
DEC C V5.8-009 on Digital UNIX V4.0 (Rev. 1091)
I guess Digital Unix (or whatever it is called today) has an alloca.h that
does the right thing. (They should really have one included in their
Linux
version.)
Falk> Now I wonder how to fix this best; one could for example:
Falk> * remove -std1 from the ccc flags
No.
Well I agree that this is not desirable, but it would be by far the
easiest solution :)
Falk> * use something like
Falk> #if defined(__DECC) && defined(__linux__)
Falk> # include <machine/builtins.h>
Falk> # define alloca __ALLOCA
Falk> #endif
Falk> which also works with -std1
I would prefer a configure test for __ALLOCA, and add some logic to
use __ALLOCA the top of src/config.h.in.
Yes, that would be the nicest solution.
Falk> * consistentialize xemacs' declarations; regex.c also
wants to declare
Falk> alloca as returning char *.
Yes. But it's hard for me to make these kinds of changes without
access to your system.
You could try to sign up for the Compaq Test Drive at
http://www.testdrive.compaq.com/accounts/register.shtml. They have a
Debian Alpha Linux system, though I'm not sure if it has the Compaq
compiler installed. (They have an IA64 system, too, BTW...)
Falk> And if anybody feels a bit bored, here are a few interesting
warnings:
These are fantastic warnings. What a great compiler! I'll fixmiscplay.c.
Incidentally, a warning feature for those sequence point problems was just
committed to the gcc tree...
Falk> cc: Warning: miscplay.c, line 384: In this statement, the
expression "*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed
char ...)(src++)))/2)" modifies the variable "src" more than once without
an intervening sequence point. This behavior is undefined. (undefvarmod)
Falk> *dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
Falk> ----^
I'd like to fix the next two, but I think I'd like the help of your
wonderful compiler to track down the stuff in the preprocessor magic.
Or you could try doing this if you'd like to help with the hacking.
Ok, I'll preprocess it and then see where exactly the compiler sees the
problem.
Falk> cc: Warning: regex.c, line 5627: This statement uses the
type "union declared without a tag" to reference the same storage location as
the statement at line number 5627 in file regex.c, which uses the type "long".
This does not conform to the ANSI aliasing rules. (badansialias)
Falk> POP_FAILURE_POINT (d, p,
Falk> ----------^
Falk
6:33 a.m.
>>>> "Falk" == Falk Hueffner
<falk.hueffner(a)student.uni-tuebingen.de> writes:
Falk> Hi,
Falk> with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I get
Falk> [...]
Falk> checking for working alloca.h... no
Falk> checking for alloca... no
Falk> Defining C_ALLOCA
Falk> checking whether alloca needs Cray hooks... no
Falk> checking stack direction for C alloca... -1
Falk> Defining STACK_DIRECTION = -1
Falk> xemacs will be linked with "alloca.o"
Falk> [...]
Here's a patch that fixes it. After I commit this, I would like
everyone (but especially Falk) who has an Alpha Linux system to test
both gcc and ccc if possible.
This is really a Compaq C bug workaround, since
#include <alloca.h>
should include a Compaq-specific header file (as gcc does), since
alloca is a compiler-dependent function, not for library implementation.
Index: ChangeLog
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/ChangeLog,v
retrieving revision 1.155.2.215
diff -u -w -U0 -r1.155.2.215 ChangeLog
--- ChangeLog 2000/10/27 05:32:53 1.155.2.215
+++ ChangeLog 2000/11/01 05:40:19
＠＠ -0,0 +1,4 ＠＠
+2000-11-01 Martin Buchholz <martin(a)xemacs.org>
+
+ * configure.in: Handle alloca with Compaq C on Alpha Linux.
+
Index: src/ChangeLog
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/ChangeLog,v
retrieving revision 1.154.2.732
diff -u -w -U0 -r1.154.2.732 ChangeLog
--- src/ChangeLog 2000/11/01 02:56:16 1.154.2.732
+++ src/ChangeLog 2000/11/01 05:40:29
＠＠ -2,0 +3,2 ＠＠
+ * config.h.in: Handle alloca with Compaq C on Alpha Linux.
+
Index: src/config.h.in
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v
retrieving revision 1.49.2.52
diff -u -w -r1.49.2.52 config.h.in
--- src/config.h.in 2000/10/27 05:29:44 1.49.2.52
+++ src/config.h.in 2000/11/01 05:40:34
＠＠ -34,7 +34,10 ＠＠
#ifndef NOT_C_CODE
#ifdef __GNUC__
#define alloca __builtin_alloca
-#elif HAVE_ALLOCA_H
+#elif defined __DECC
+#include <alloca.h>
+#pragma intrinsic(alloca)
+#elif defined HAVE_ALLOCA_H
#include <alloca.h>
#elif defined(_AIX)
#pragma alloca
Index: configure.in
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v
retrieving revision 1.111.2.130
diff -u -w -r1.111.2.130 configure.in
--- configure.in 2000/10/27 05:32:52 1.111.2.130
+++ configure.in 2000/11/01 05:40:41
＠＠ -3698,8 +3698,11 ＠＠
dnl AC_CHECK_FUNC(alloca, [:], [AC_CHECK_LIB(PW, alloca)])
dnl esac
+dnl AC_FUNC_ALLOCA doesn't know about DEC C's #pragma intrinsic(alloca)
+if test "$__DECC" != "yes"; then
AC_FUNC_ALLOCA
test -n "$ALLOCA" && XE_ADD_OBJS($ALLOCA)
+fi
dnl Check whether vfork exists and works correctly. (This does more
dnl than just check for its existence.) If so, it defines HAVE_VFORK_H.
2:03 a.m.
Soon to be applied to 21.1. This patch will be in 21.1.13.
- vin
Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "Falk" == Falk Hueffner
<falk.hueffner(a)student.uni-tuebingen.de> writes:
Falk> Hi,
Falk> with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I get
Falk> [...]
Falk> checking for working alloca.h... no
Falk> checking for alloca... no
Falk> Defining C_ALLOCA
Falk> checking whether alloca needs Cray hooks... no
Falk> checking stack direction for C alloca... -1
Falk> Defining STACK_DIRECTION = -1
Falk> xemacs will be linked with "alloca.o"
Falk> [...]
Here's a patch that fixes it. After I commit this, I would like
everyone (but especially Falk) who has an Alpha Linux system to test
both gcc and ccc if possible.
This is really a Compaq C bug workaround, since
#include <alloca.h>
should include a Compaq-specific header file (as gcc does), since
alloca is a compiler-dependent function, not for library implementation.
Index: ChangeLog
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/ChangeLog,v
retrieving revision 1.155.2.215
diff -u -w -U0 -r1.155.2.215 ChangeLog
--- ChangeLog 2000/10/27 05:32:53 1.155.2.215
+++ ChangeLog 2000/11/01 05:40:19
＠＠ -0,0 +1,4 ＠＠
+2000-11-01 Martin Buchholz <martin(a)xemacs.org>
+
+ * configure.in: Handle alloca with Compaq C on Alpha Linux.
+
Index: src/ChangeLog
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/ChangeLog,v
retrieving revision 1.154.2.732
diff -u -w -U0 -r1.154.2.732 ChangeLog
--- src/ChangeLog 2000/11/01 02:56:16 1.154.2.732
+++ src/ChangeLog 2000/11/01 05:40:29
＠＠ -2,0 +3,2 ＠＠
+ * config.h.in: Handle alloca with Compaq C on Alpha Linux.
+
Index: src/config.h.in
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v
retrieving revision 1.49.2.52
diff -u -w -r1.49.2.52 config.h.in
--- src/config.h.in 2000/10/27 05:29:44 1.49.2.52
+++ src/config.h.in 2000/11/01 05:40:34
＠＠ -34,7 +34,10 ＠＠
#ifndef NOT_C_CODE
#ifdef __GNUC__
#define alloca __builtin_alloca
-#elif HAVE_ALLOCA_H
+#elif defined __DECC
+#include <alloca.h>
+#pragma intrinsic(alloca)
+#elif defined HAVE_ALLOCA_H
#include <alloca.h>
#elif defined(_AIX)
#pragma alloca
Index: configure.in
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v
retrieving revision 1.111.2.130
diff -u -w -r1.111.2.130 configure.in
--- configure.in 2000/10/27 05:32:52 1.111.2.130
+++ configure.in 2000/11/01 05:40:41
＠＠ -3698,8 +3698,11 ＠＠
dnl AC_CHECK_FUNC(alloca, [:], [AC_CHECK_LIB(PW, alloca)])
dnl esac
+dnl AC_FUNC_ALLOCA doesn't know about DEC C's #pragma intrinsic(alloca)
+if test "$__DECC" != "yes"; then
AC_FUNC_ALLOCA
test -n "$ALLOCA" && XE_ADD_OBJS($ALLOCA)
+fi
dnl Check whether vfork exists and works correctly. (This does more
dnl than just check for its existence.) If so, it defines HAVE_VFORK_H.
8854
days inactive
8920
days old
4 comments
3 participants
participants (3)
-
Falk Hueffner -
Martin Buchholz -
Vin Shelton