fftw-3.0.1-fma + Lynxos+PPC G4 fails tests.

[Fabio Garufi]

Hi, all,
I built the fftw-3.0.1-fma on a LynxOS 4.0 running on a board equipped
with a PowerPC G4 7457. To compile it I had to slightly modify the
configure
script to use the -fvec instead of -faltivec and use the
our-malloc16 function. I never could run the checks in tests directory,
since they always failed with signal 11.
Here follow the core dump and an excerpt from the config.log:

core:
---------------> thread ID = 24 <---------------
Stopped at _SDA_BASE_+0xc070f3ec error 4 (Instruction Storage
Interrupt)
@ d9010 (data/bss/heap)
link register t_shift+0x2bc
Called from t_shift+0x24c
Called from verify_r2r+0x3f4
Called from verify+0xc8
Called from bench_main+0x244
Called from aligned_main+0x10
Called from main+0x10
Called from _start+0x6c
Called from __deregister_frame_info+0x0

Brk: 000d9610 Stack: 104c9000 Brk limit: 0fa00000 Bytes left: 0f9269f0

sp : 104ca750 toc : 0 xer : 20000000 ctr: 1 srr0: c07e1840
R3 R4 R5 R6 R7 R8 R9 R10
00000001 bfc11602 40779b02 000003bc 000000ef 000000ef 00000000 000000ef
R11 R12 R13 R14 R15 R16 R17 R18
000000f0 00000014 00000000 000d8000 000d4610 00000001 00000001 000000f0

config.log:

$

../configure --disable-fortran --enable-fma --enable-altivec --enable-float -
-with-our-malloc16

## --------- ##
## Platform. ##
## --------- ##

hostname = show7
uname -m = PowerPC
uname -r = 4.0.0
uname -s = LynxOS
uname -v = 021802-G

Any help appreciated...


--
------------------------------------------------------------------------
** Dr. Fabio Garufi
** Software Manager
**
** ELE.SI.A. S.p.A.
** ISO 9001 CERTIFIED
** Tel. [phone] / Fax [phone]
** http://www.elesia.it
------------------------------------------------------------------------

[jacob navia]

Fabio Garufi wrote:

Hi, all,
I built the fftw-3.0.1-fma on a LynxOS 4.0 running on a board equipped
with a PowerPC G4 7457. To compile it I had to slightly modify the
configure
script to use the -fvec instead of -faltivec and use the
our-malloc16 function. I never could run the checks in tests directory,
since they always failed with signal 11.
Here follow the core dump and an excerpt from the config.log:

core:
---------------> thread ID = 24 <---------------
Stopped at _SDA_BASE_+0xc070f3ec error 4 (Instruction Storage
Interrupt)
@ d9010 (data/bss/heap)
link register t_shift+0x2bc
Called from t_shift+0x24c
Called from verify_r2r+0x3f4
Called from verify+0xc8
Called from bench_main+0x244
Called from aligned_main+0x10
Called from main+0x10
Called from _start+0x6c
Called from __deregister_frame_info+0x0

Brk: 000d9610 Stack: 104c9000 Brk limit: 0fa00000 Bytes left: 0f9269f0

sp : 104ca750 toc : 0 xer : 20000000 ctr: 1 srr0: c07e1840
R3 R4 R5 R6 R7 R8 R9 R10
00000001 bfc11602 40779b02 000003bc 000000ef 000000ef 00000000 000000ef
R11 R12 R13 R14 R15 R16 R17 R18
000000f0 00000014 00000000 000d8000 000d4610 00000001 00000001 000000f0

config.log:

$

./configure --disable-fortran --enable-fma --enable-altivec --enable-float -
-with-our-malloc16

## --------- ##
## Platform. ##
## --------- ##

hostname = show7
uname -m = PowerPC
uname -r = 4.0.0
uname -s = LynxOS
uname -v = 021802-G

Any help appreciated...

You have to debug. What line is failing?
Did you compile with debug info?
As the core dump shows, probably that is the case.

Then:

start your debugger, run the program, and see what line is
failing. Look at the values of the variables at the point
of failure. Do they look OK?

This is something every C programmer must learn: debugging is
a difficult art.

jacob

[Fabio Garufi]

The problem is that the failure is in a library function and I have not
compiled the library with the debug option.
Anyway I can trace down where the program fails, because t_shift appears
only once in the verify_r2r.c file: function:
void verify_r2r(bench_problem *p, int rounds, double tol, errors *e)

The function t_shift is also define therein, and it fails in a loop, just
before the call to raphase_shift():
[...]
dofft(nfo, inA, outA);
dofft(nfo, inB, outB);
for (i = 0; i < vecn; ++i)
raphase_shift(tmp + i * n, outA + i * n, ncur,
nb, na, d[dim].n0, d[dim].k0, d[dim].ts);

....as objdump shows:
000011d0 <t_shift>:

static double t_shift(int n, int vecn, info *nfo,
R *inA, R *inB, R *outA, R *outB, R *tmp,
int rounds, double tol,
dim_stuff *d)
{
[...]
1348: 38 a1 00 20 addi r5,r1,32
nfo->p->k[dim]);
}
dofft(nfo, inA, outA);
dofft(nfo, inB, outB);
for (i = 0; i < vecn; ++i)
134c: 3b e0 00 00 li r31,0
1350: 80 7b 00 0c lwz r3,12(r27)
1354: 80 09 00 20 lwz r0,32(r9)
1358: 3d 20 00 00 lis r9,0
135c: 80 9b 00 08 lwz r4,8(r27)
1360: 39 29 00 00 addi r9,r9,0
1364: 90 01 00 28 stw r0,40(r1)
1368: 91 21 00 20 stw r9,32(r1)
136c: 91 c1 00 24 stw r14,36(r1)
1370: 48 00 00 01 bl 1370 <t_shift+0x1a0>
1374: 80 9b 00 00 lwz r4,0(r27)
1378: 38 60 00 01 li r3,1
137c: 48 00 00 01 bl 137c <t_shift+0x1ac>
1380: 81 3b 00 00 lwz r9,0(r27)
1384: 38 a1 00 40 addi r5,r1,64
1388: 81 61 00 b8 lwz r11,184(r1)
138c: 80 09 00 24 lwz r0,36(r9)
1390: 3d 20 00 00 lis r9,0
1394: 80 7b 00 08 lwz r3,8(r27)
1398: 80 9b 00 0c lwz r4,12(r27)
139c: 39 29 00 00 addi r9,r9,0
13a0: 91 21 00 40 stw r9,64(r1)
13a4: 90 01 00 44 stw r0,68(r1)
13a8: 91 61 00 48 stw r11,72(r1)
13ac: 48 00 00 01 bl 13ac <t_shift+0x1dc>
13b0: 81 3b 00 00 lwz r9,0(r27)
13b4: 38 a1 00 70 addi r5,r1,112
13b8: 80 7b 00 0c lwz r3,12(r27)
13bc: 80 09 00 20 lwz r0,32(r9)
13c0: 3d 20 00 00 lis r9,0
13c4: 80 9b 00 08 lwz r4,8(r27)
13c8: 81 61 00 b4 lwz r11,180(r1)
13cc: 39 29 00 00 addi r9,r9,0
13d0: 91 21 00 70 stw r9,112(r1)
13d4: 91 61 00 74 stw r11,116(r1)
13d8: 90 01 00 78 stw r0,120(r1)
13dc: 48 00 00 01 bl 13dc <t_shift+0x20c>
13e0: 80 9b 00 00 lwz r4,0(r27)
13e4: 38 60 00 01 li r3,1
13e8: 48 00 00 01 bl 13e8 <t_shift+0x218>
13ec: 81 3b 00 00 lwz r9,0(r27)
13f0: 38 a1 00 90 addi r5,r1,144
13f4: 80 7b 00 08 lwz r3,8(r27)
13f8: 80 09 00 24 lwz r0,36(r9)
13fc: 3d 20 00 00 lis r9,0
1400: 80 9b 00 0c lwz r4,12(r27)
1404: 39 29 00 00 addi r9,r9,0
1408: 81 61 00 bc lwz r11,188(r1)
140c: 91 21 00 90 stw r9,144(r1)
1410: 90 01 00 94 stw r0,148(r1)
1414: 91 61 00 98 stw r11,152(r1)
1418: 48 00 00 01 bl 1418 <t_shift+0x248>
141c: 7c 1f 88 00 cmpw r31,r17
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1420: 40 80 00 c8 bge 14e8 <t_shift+0x318>
1424: 80 01 00 c8 lwz r0,200(r1)
1428: 81 21 01 50 lwz r9,336(r1)
142c: 7f 80 4a 14 add r28,r0,r9
raphase_shift(tmp + i * n, outA + i * n, ncur,

What cannot be traced is the value of variables.
--
------------------------------------------------------------------------
** Dr. Fabio Garufi
** Software Manager
**
** ELE.SI.A. S.p.A.
** ISO 9001 CERTIFIED
** Tel. [phone] / Fax [phone]
** http://www.elesia.it
------------------------------------------------------------------------
"jacob navia" <ja***@jacob.remcomp.fr> ha scritto nel messaggio
news:41**********************@news.wanadoo.fr...

Fabio Garufi wrote:

Hi, all,
I built the fftw-3.0.1-fma on a LynxOS 4.0 running on a board equipped with a PowerPC G4 7457. To compile it I had to slightly modify the
configure
script to use the -fvec instead of -faltivec and use the
our-malloc16 function. I never could run the checks in tests directory,
since they always failed with signal 11.
Here follow the core dump and an excerpt from the config.log:

core:
---------------> thread ID = 24 <---------------
Stopped at _SDA_BASE_+0xc070f3ec error 4 (Instruction Storage
Interrupt)
@ d9010 (data/bss/heap)
link register t_shift+0x2bc
Called from t_shift+0x24c
Called from verify_r2r+0x3f4
Called from verify+0xc8
Called from bench_main+0x244
Called from aligned_main+0x10
Called from main+0x10
Called from _start+0x6c
Called from __deregister_frame_info+0x0

Brk: 000d9610 Stack: 104c9000 Brk limit: 0fa00000 Bytes left: 0f9269f0

sp : 104ca750 toc : 0 xer : 20000000 ctr: 1 srr0: c07e1840
R3 R4 R5 R6 R7 R8 R9 R10
00000001 bfc11602 40779b02 000003bc 000000ef 000000ef 00000000 000000ef
R11 R12 R13 R14 R15 R16 R17 R18
000000f0 00000014 00000000 000d8000 000d4610 00000001 00000001 000000f0

config.log:

$

../configure --disable-fortran --enable-fma --enable-altivec --enable-float - -with-our-malloc16

## --------- ##
## Platform. ##
## --------- ##

hostname = show7
uname -m = PowerPC
uname -r = 4.0.0
uname -s = LynxOS
uname -v = 021802-G

Any help appreciated...

You have to debug. What line is failing?
Did you compile with debug info?
As the core dump shows, probably that is the case.

Then:

start your debugger, run the program, and see what line is
failing. Look at the values of the variables at the point
of failure. Do they look OK?

This is something every C programmer must learn: debugging is
a difficult art.

jacob

[Jens.Toerring]

Fabio Garufi <fg*****@elesia.it> wrote:

I built the fftw-3.0.1-fma on a LynxOS 4.0 running on a board equipped
with a PowerPC G4 7457. To compile it I had to slightly modify the
configure
script to use the -fvec instead of -faltivec and use the
our-malloc16 function. I never could run the checks in tests directory,
since they always failed with signal 11.
Here follow the core dump and an excerpt from the config.log:

<snipped>

Unfortunately, your question isn't really related to the language C,
the topic of this group. But typically a signal 11 is due to a seg-
mentation fault, which means that your program tries to access some
memory it has no permission to access (or which does not exist). That
also would mean that the reason for the crash might not be related at
all to the exact place where the crash happens but may be somewhere
else in code that has been executed previously. Therefor trying to
figure out what's going wrong by concentrating on just that line of
code could be rather useless. Probably your best bet is trying to run
the program under some memory debugger for your system (if that exists)
or ask the people that wrote "fftw-3.0.1-fma" (whatever that exactly is)
for help.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de