I've added your suggested changes. It will be an hour or so until compilation is finished. Slackware CFLAGS or CXXFLAGS are usually -O2 by default.

Cheers,

Fred

On 03/16/2012 02:09 PM, Tom Rondeau wrote:
On Fri, Mar 16, 2012 at 3:03 PM, Frederick Stevens <sk8tesgr...@gmail.com <mailto:sk8tesgr...@gmail.com>> wrote:

    Here is the gcc info.  It will take me a bit to re compile
    gnuradio but I will turn on debugging in cmake.

    gcc (GCC) 4.5.2
    Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
    PURPOSE.

    I am running kernel 3.2.7 from slackware-current and swig 2.0.4
    everything else is from slackbuilds.  I will have to get versions
    for you if you need them.

    Cheers,

    Fred


While you're doing the rebuild, can you set the optimization flag to -O2? It's -O3 right now by default, and every now and then it can be a problem (haven't heard of one in a while, but it's been a thing).

It should be setting '-DCMAKE_CXXFLAGS="-O2"'.

Tom


    On 03/16/2012 01:50 PM, Nick Foster wrote:
    On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens
    <sk8tesgr...@gmail.com <mailto:sk8tesgr...@gmail.com>> wrote:

        Rafael,

        Here is the output from gdb:

        RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a

        Program received signal SIGSEGV, Segmentation fault.
        0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic ()
          from
        /home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0



        Dump of assembler code for function
        volk_32fc_32f_multiply_32fc_a_generic:
          0xb7f2c6c0 <+0>:     push   %ebp
          0xb7f2c6c1 <+1>:     mov    %esp,%ebp
          0xb7f2c6c3 <+3>:     push   %edi
          0xb7f2c6c4 <+4>:     push   %esi
          0xb7f2c6c5 <+5>:     mov    0x8(%ebp),%edx
          0xb7f2c6c8 <+8>:     mov    0xc(%ebp),%ecx
          0xb7f2c6cb <+11>:    mov    0x10(%ebp),%edi
          0xb7f2c6ce <+14>:    mov    0x14(%ebp),%esi
          0xb7f2c6d1 <+17>:    test   %esi,%esi
          0xb7f2c6d3 <+19>:    je     0xb7f2c6fc
        <volk_32fc_32f_multiply_32fc_a_generic+60>
          0xb7f2c6d5 <+21>:    xor    %eax,%eax
          0xb7f2c6d7 <+23>:    mov    %esi,%esi
          0xb7f2c6d9 <+25>:    lea    0x0(%edi,%eiz,1),%edi
        => 0xb7f2c6e0 <+32>:    flds   (%edi,%eax,8)
          0xb7f2c6e3 <+35>:    flds   (%ecx,%eax,8)
          0xb7f2c6e6 <+38>:    fmul   %st(1),%st
          0xb7f2c6e8 <+40>:    fxch   %st(1)
          0xb7f2c6ea <+42>:    fmuls  0x4(%ecx,%eax,8)
          0xb7f2c6ee <+46>:    fxch   %st(1)
          0xb7f2c6f0 <+48>:    fstps  (%edx,%eax,8)
          0xb7f2c6f3 <+51>:    fstps  0x4(%edx,%eax,8)
          0xb7f2c6f7 <+55>:    inc    %eax
          0xb7f2c6f8 <+56>:    cmp    %eax,%esi
          0xb7f2c6fa <+58>:    ja     0xb7f2c6e0
        <volk_32fc_32f_multiply_32fc_a_generic+32>
          0xb7f2c6fc <+60>:    pop    %esi
          0xb7f2c6fd <+61>:    pop    %edi
          0xb7f2c6fe <+62>:    pop    %ebp
          0xb7f2c6ff <+63>:    ret
        End of assembler dump.

        I omitted the first part of the program execution since
        everything seemed to be working fine.  Hope this helps.  Let
        me know if you would like me to try something else.

        Cheers,


        Fred


    OK, that's weird as hell. That's the generic implementation,
    which is just a std::complex multiply in a for loop. Can you give
    me your gcc version?

    --n





        On 03/16/2012 12:39 PM, Rafael Diniz wrote:

            Also using the gdb "disassemble" command you could trace
            which instruction
            raised the fault.

            Cheers,
            Rafael Diniz

                Well, that doesn't make me happy at all. Especially
                since we just patched
                the release yesterday...

                Sounds like the AMD chip is handling something wrong
                (or differently) with
                the alignment. All vectors passed using volk_profile
                are supposed to be
                properly byte aligned.

                Fred, can you just check for me what happens when you
                run it under gdb?
                Just run "gdb volk_profile" and when it crashes, do a
                "bt" and post the
                results of the backtrace here.

                Thanks,
                Tom



            _______________________________________________
            Discuss-gnuradio mailing list
            Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
            https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



        _______________________________________________
        Discuss-gnuradio mailing list
        Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




    _______________________________________________
    Discuss-gnuradio mailing list
    Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
    https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to