[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf bug
From: |
Joerg Schilling |
Subject: |
Re: autoconf bug |
Date: |
Sun, 13 Jul 2003 12:36:51 +0200 (CEST) |
>From address@hidden Thu Jul 10 08:58:49 2003
>(CC'ing to bug-autoconf)
>Joerg Schilling <address@hidden> writes:
>> find_stack_direction()
>> {
>> static char *addr = 0;
>> auto char dummy;
>> if (addr == 0) {
>> addr = &dummy;
>> return find_stack_direction ();
>> } else {
>> return (&dummy > addr) ? 1 : -1;
>> }
>> }
>>
>> found in acspecific.m4 is not working correctly because
>> GCC optimizes this code in a way that &dummy may be == addr.
>Thanks for the bug report. If I understand you correctly, it's a GCC
>bug, as that behavior doesn't conform to the C standard. We should
>file a bug report. Which version of GCC was it, and on what platform?
Why would you call this a GCC bug?
GCC just detects that 'dummy' is not (except for an address) used and does
not reserve stack space for this object.
In the usual case, when ./configure is called without parameters/environ,
then GCC does not optimize and the code above gives the expected results
except for the fact that is is lazy code anyway and ignores the possibility
that &dummy may be == addr.
If you call env CC=gcc -O' ./configure
then the test does not work and while code:
int
stack_direction(lp)
long *lp;
{
auto long *dummy[4];
int i;
for (i=0; i < 4; i++)
dummy[i] = lp;
if (lp == 0) {
return (stack_direction((long *)dummy));
} else {
if ((long *)dummy == lp)
return (0);
return (((long *)dummy > lp) ? 1 : -1);
}
}
still works.
BTW: the tests have been made on Solaris x86.
>Hmm, but we can't simply modify acspecific.m4; we also need to modify
>alloca.c, so that it is consistent with acspecific.m4.
Then you should also fuile a bug against GCC
>But I'm puzzled as to why this matters, if you're using GCC.
>GCC has builtin alloca, so shouldn't this issue be moot for GCC?
????
I was just working on a portable software signal system that needs to
know the direction in which the stack grows... so I was looking for a
usable test mechanism.
After I run my tests on all plartforms that I have in our reseach
institute, I found that HP-PA uses a stack that grows to higher addresses.
Jörg
--
EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
address@hidden (uni) If you don't have iso-8859-1
address@hidden (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling
ftp://ftp.berlios.de/pub/schily