Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG wrote: >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> >>>Ah, I have found the problem. The Debian package builds gf2pbm with >>>optimization on (-O2). gf2pbm misbehaves when compiled with >>>optimization, and works fine when compiled without. >> More specifically, failure happens with: >> -fschedule-insns -fstrict-aliasing -O >> But not with: -O or either of those -f optimizations alone. > > there are some dodgy pointer casts in gf2pbm, specifically, > > gf2pbm.c: In functie $-1òøread_GF_charòù: > gf2pbm.c:305: let op: initialization from incompatible pointer type > > BMUNIT *cp, *basep, *maxp; > char **basep_cpp = &basep; > > GCC4 has become much more agressive with considering cast pointers as > unaliased by definition, so I would suspect this one.
Yep, I've narrowed it down to that one too (I didn't think the warning at first should matter)! If I change the declaration to "BMUNIT **basep_cpp", that of course shuts up the warning. And--it causes the failure to happen whether optimization is on or not! The problem is almost certainly the type punning of the basep_cpp variable and the creepy pointer arithmetic being done with what it points to. When the declaration is fixed to shup up the warning, the result is that the same thing happens as when the compiler assumed there was no aliasing, and that's that the pointer arithmetic is multiplied by the wrong things. It would of course help if there were comments! :) :) I'm attempting a fix now. Thomas _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
