[PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???)
damon at karuna.eclipse.co.uk
Fri Aug 14 14:03:10 CEST 2009
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
> 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
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:
float_value = fv;
if (u.int_value & 0x7f800000)
fv = 0.0f;
The gcc info docs mention this issue, under the -fstrict-aliasing
More information about the Pd-dev