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

From: Fabio Garufi (fgarufi_at_elesia.it)
Date: 10/26/04 

Date: Tue, 26 Oct 2004 15:55:44 +0200

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. +39.0774.3653.227 / Fax +39.0774.3653.300
** http://www.elesia.it
------------------------------------------------------------------------
"jacob navia" <jacob@jacob.remcomp.fr> ha scritto nel messaggio
news:417e36bf$0$3682$8fcfb975@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

Relevant Pages

  • Re: Debug Vs Release
    ... > If I compile that code in debug mode then dissassemble the EXE, ... > private static void Main(stringargs) ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: SUnit disappointment
    ... I always press the 'Debug' button in the SUnitBrowser when I'm ... For example when examining a failure in the debugger rather ... I'll often be able to fix the failure in my second ... > Equals verify: object printString with: 'test' ...
    (comp.lang.smalltalk.dolphin)
  • Re: Getting a stack trace from a running application
    ... Unfortunately, the only infromation they can provide is a memory address, which is pretty useless as it doesn't tell me if my main exe is the culprit or if it's some dll or ocx or whatever. ... If you compile the the program with debug information, the debugger will show the responsible line of your code that caused the error. ...
    (comp.lang.basic.visual.misc)
  • Re: copymemory basic question
    ... I have used that technique before; that is, put a MessageBox in a VC program ... workspace and then debug the program without using the MessageBox or MsgBox. ... > - Compile and save. ... not able to show anything due to the optimization. ...
    (microsoft.public.vb.winapi)
  • Re: MustInherit in Window forms
    ... #If Debug then ... Public MustInherit BaseClass ... compile in Release mode. ... the Base form to implement DisconnectFromAbrServer. ...
    (microsoft.public.dotnet.languages.vb)