Michel Dänzer <[EMAIL PROTECTED]> writes:
> On Thu, 2004-01-01 at 18:59, Lukas Geyer wrote:
> >
> > OK, this really seems to be two different bugs. I get an illegal
> > instruction in "make smallcheck" on this iBook G3.
>
> On the same test?
Yes, though the tests are random and it sometimes seems to do fine for
a moment and then crashes. Here is a test run:
perl -w ./check.pl -r -c=1 -v `pwd`/bench
Executing "/home/lukas/fftw3-3.0.1/tests/bench --verbose=1 --verify
ok10o11x7o00*26 --verify ik10o11x7o00*26 --verify obr11x8v2 --verify ibr11x8v2
--verify ofr11x8v2 --verify ifr11x8v2 --verify /obc11x8v2 --verify /ibc11x8v2
--verify /ofc11x8v2 --verify /ifc11x8v2 --verify obc11x8v2 --verify ibc11x8v2
--verify ofc11x8v2 --verify ifc11x8v2"
FAILED /home/lukas/fftw3-3.0.1/tests/bench: --verify ok10o11x7o00*26 --verify
ik10o11x7o00*26 --verify obr11x8v2 --verify ibr11x8v2 --verify ofr11x8v2
--verify ifr11x8v2 --verify /obc11x8v2 --verify /ibc11x8v2 --verify /ofc11x8v2
--verify /ifc11x8v2 --verify obc11x8v2 --verify ibc11x8v2 --verify ofc11x8v2
--verify ifc11x8v2
received signal 4
make: *** [smallcheck] Error 1
OK, I compiled everything with -g now, and gdb gives me the following
on the core dump. (Output cut down to the relevant parts.)
Core was generated by `lt-bench --verbose=1 --verify ok10o11x7o00*26 --verify
ik10o11x7o00*26 --verify'.
Program terminated with signal 4, Illegal instruction.
[...]
#0 0x0fe8f0f0 in n1bv_11 (ri=0x1c, ii=0x7ffff170, ro=0x1003f1b0,
io=0x1003ec54, is=268692560, os=268692564, v=268692560, ivs=268693936,
ovs=0) at n1bv_11.c:43
43 {
(gdb) info all-registers
[...]
pc 0xfe8f0f0 266924272
[...]
(gdb) disas
Dump of assembler code for function n1bv_11:
0x0fe8f0ec <n1bv_11+0>: stwu r1,-544(r1)
0x0fe8f0f0 <n1bv_11+4>: mfvrsave r12
0x0fe8f0f4 <n1bv_11+8>: stw r12,532(r1)
[...]
I am no PPC assembler expert, but it seems that mfvrsave is an Altivec
instruction, no? Somehow this shouldn't be linked in on a non-Altivec,
right? Well, maybe someone with more clue can start from here and see
what exactly goes wrong in the build. For the record, the problem is
the same in all n1bv_* codelets, and the illegal instruction happen
randomly in one of them. (At least in other tests I had it bomb in
n1bv_2.c and n1bv_13.c...)
> > The gcc version is the most recent in sid. Should I file another FTBFS bug
> > about this?
>
> Guess so...
If the maintainer uploads a new version without altivec support, this
would be moot anyway. James?
Lukas
