On Mon, Jun 10, 2013 at 6:12 PM, <[email protected]> wrote:
> > For the modem port I had some test scripts that evaluated the error
> > ranges, like 1E-4 between the Octave and C code. For the STM port work
> > I have some code and Octave that dumps internal codec states to allow
> > finer grained comparisons, but it's not automated.
>
> David,
>
> As far as I'm aware, Richard is able to get the results closer to what you
> expect - on one platform - by turning off optimizations, but this is
> resulting in either slower code or the testing of non-production code, and
> it doesn't work across platforms. I don't see what means we have of
> identifying that a new port does not expose some new bug.
Nothing will be slower, in fact, depending on the situation, -O3 can be
slower than -O2... The "RelWithDebInfo" still creates a "release" binary
but the debuginfo part is still available for running through gdb/stack
traces... Everything from Fedora is built this way but the debuginfo parts
are split out into a debuginfo package to save space if/until you need it.
Richard
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
