Re: Problems with alloca on Alpha Linux with Compaq cc
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