On Fri, 2009-08-14 at 04:07 -0700, Ed Kelly wrote:
We have to sort this out!
The denormals bug in freeverb~ _seems_ to have been fixed by following Julius' advice. I made a makefile with
-fno-trapping-math
as a flag and so far so good. I haven't had a problem with the freeverb~ object pegging the CPU. May I advise that this is implemented in PD-extended, since it causes my patch to NOT WORK AT GIGS! I simply cannot take any more embarrassment. I want to play live, otherwise there's simply no point doing anything!
The second one I have discovered is in bsaylor/svf~ and there's no makefile for this in the subversion repository. I notice in the source code there is a FLUSH_TO_ZERO definition. Interestingly, when I try to compile this external using a bog-standard makefile on Ubuntu 8.10, it causes an error:
cc1: warnings being treated as errors svf~.c: In function ‘run_svf’: svf~.c:59: error: dereferencing type-punned pointer will break strict-aliasing rules svf~.c:60: error: dereferencing type-punned pointer will break strict-aliasing rules
Now, I'm trying to unpick the statement: #define FLUSH_TO_ZERO(fv) (((*(unsigned int*)&(fv))&0x7f800000)==0)?0.0f:(fv)
which is being called on lines 59 and 60 of bsaylor/svf~.c, causing the compiler to choke, and (perhaps) causing my drumsynths to break!
I just reported a problem with the same FLUSH_TO_ZERO macro in the TAP LADSPA plugins.
The macro is trying to check the value to see if it is a denormal, and if so it sets it to 0. However, to do that it is accessing a float by casting it to an int, which can cause problems if compiled with -O3, hence the warning/error above.
I think you can avoid the problem by using a union, e.g. something like:
union { float float_value; uint32_t int_value; } u;
float_value = fv; if (u.int_value & 0x7f800000) fv = 0.0f;
The gcc info docs mention this issue, under the -fstrict-aliasing optimization option.
Damon