reassign 356896 gcc-4.1 4.1.0-0
severity 356896 serious
retitle 356896 gcc 4.1 miscompiles apcalc (again)
thanks
On Sat, Mar 18, 2006 at 11:10:57PM +0000, Martin Michlmayr wrote:
> That's the smallest test case I can come up with:
>
> $ cat test.cal
> global prob;
> define test_booleans()
> {
> if (0)
> print '**** if (0)';
>
> if (1)
> print '301: if (1)';
>
> if (2)
> print '302: if (2)';
>
> }
> ./calc -d -q read ./test
> zsh: segmentation fault ./calc -d -q read ./test
I guess the gcc maintainers would prefer a test case in C ;-) , so here we
go (extremely simplified compared to the original apcalc source which
triggers the bug in its stralloc() function).
$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
#define LEN 100
int
main(void) {
int *tmp, *start;
start = malloc(sizeof(*start) * LEN);
for (tmp = start + LEN; tmp > start; --tmp) ;
printf("start: %p, tmp: %p\n", (void *)start, (void *)tmp);
return 0;
}
$ gcc-4.1 -O1 foo.c
$ ./a.out
start: 0x804a050, tmp: 0x804a1dc
$ gcc-4.0 -O1 foo.c
$ ./a.out
start: 0x804a050, tmp: 0x804a050
$
Note that with gcc 4.1, the for loop exits prematurely before tmp <= start,
while gcc 4.0 behaves correctly. Compilling with -O0 "fixes" the problem
also with gcc 4.1.
I tested on x86, but apparently, the bug also affects other architectures.
BTW, at the risk of repeating myself: I'd strongly recommend using apcalc
as a test suite for gcc release candidates. There have been numerous cases
in the past where apcalc FTBFS'd, and in each case I can remember where
apcalc's test suite failed, this was caused by a gcc bug, not by a bug in
apcalc.
BTW#2, apcalc also failed with gcc 4.0 on arm and m68k and I haven't
verified whether these problems still exist in 4.1. So you might want to
test somewhere else to avoid searching for two bugs at the same time.
Thanks,
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
