On Tue, May 25, 2010 at 08:05:11PM +0200, sean finney wrote: > hi, > > On Tue, May 25, 2010 at 08:44:57AM +0200, Iustin Pop wrote: > > I understand your point, and I'm fine with the bug being reopened. But > > personally, I do not believe anymore this is a software bug, but simply a > > compiler bug. > > I think i've already shown pretty clearly that there are signed overflow > bugs in the code. I don't think this is up for debate. The build success > by passing some syntatic sugar to the compiler lowers the severity of the > bug (it's no longer RC, at least until it's shown that it is problematic > in real life), but it doesn't make the overflows disappear.
My point is that, if the behaviour is consistent, and upstream relies on it, it's not buggy. Buggy is gcc that changes results between -O0 and -O2, and *only* on arm. > did you try > re-running the build with -ftrapv in the cmdline? i'm guessing not... Are you saying that overflows, under any conditions, are wrong? > or > have you also applied the above mentioned patches in the meantime? I'm missing your two XOR changes patches. > > Note that I say this while I admit I don't have full grasp of the > > signed overflow situation here. However: > > - gcc 4.3 was fine on armel > > - gcc 4.4 is fine on armel given no optimizations > > i would hazard a guess that the problems are still there but that you > don't see them because the tests are passing and thus the package builds. > istr that running with -O0 -ftrapv still produces an abort(), which would > definitively confirm that the overflow bugs are still there. I still don't understand why consistent overflow behaviour is wrong, or not allowed to be used. As far as I see, upstream relies on the semantics of the overflow, and on all platforms (except armel + gcc 4.4) they are consistent. > honestly, without digging deeper this sounds to me more like "i inserted a > printf() and it stopped crashing, so we have to keep the printf() in there". I respectfully disagree. > i really don't have a great deal of time for this issue right now (i haven't > tried contacting upstream beyond the first attempt when they were on > vacation). > i will see if i can get access to another sheevaplug in the meantime to > re-run a build of the new "fixed" version. Waiting for your results then. regards, iustin
signature.asc
Description: Digital signature
