I think there are several places where "strict-aliasing" isn't followed. I always compile with -fno-strict-aliasing to prevent problems.
cheers Miller On Wed, Apr 18, 2007 at 11:19:20AM -0400, Hans-Christoph Steiner wrote: > > So it seems that this bug in d_math.c is triggered by turning on the > Apple-recommended optimization flags: > > http://sourceforge.net/tracker/index.php? > func=detail&aid=1692649&group_id=55736&atid=478070 > > I did notice that there are these warnings in the source. IIRC, > optimization generally requires strict aliasing, so it seems that > these warnings are probably related to the above bug: > > d_math.c: In function 'init_rsqrt': > d_math.c:79: warning: dereferencing type-punned pointer will break > strict-aliasing rules > d_math.c: In function 'q8_rsqrt': > d_math.c:93: warning: dereferencing type-punned pointer will break > strict-aliasing rules > d_math.c: In function 'q8_sqrt': > d_math.c:101: warning: dereferencing type-punned pointer will break > strict-aliasing rules > > Here are the lines in question: > > 79: *(long *)(&f) = l; > 93: long l = *(long *)(&f); > 101: long l = *(long *)(&f); > > Can anyone speak to what's this for and what it can be replaced with > so as to follow "strict-aliasing rules". Maybe we could use > something like this instead (from http://www.cs.tut.fi/~jkorpela/ > round.html ): > > #define round(x) ((x) < LONG_MIN-0.5 || (x) > LONG_MAX+0.5 ?\ > error() : ((x)>=0?(long)((x)+0.5):(long)((x)-0.5)) > > This requires that you have #include <limits.h> and that you have an > error handling routine called error which is a function of type long. > > > .hc > > ------------------------------------------------------------------------ > ---- > > kill your television > > > > _______________________________________________ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
