On Tue, May 25, 2010 at 08:25:37AM +0200, sean finney wrote: > reopen 572923 > severity 572923 important > thanks > > hi iustin, > > Unfortunately I don't think that change is sufficient to "fix" the bug. > With signed overflows the app slides into undefinedbehaviorland as soon > as it occurs so while the unoptimized function might catch when it is > going to happen or has happened, and the unit tests pass, the overflow > still occurs. therefore i'm reopening the bug but downgrading the > severity since it does not (seem) to have a critical effect on the sw > at this point.
Hi sean, 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. 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 - gcc 4.3 and 4.4 is fine on all other architectures And I know this code is widely used in practice. So, unless either upstream confirms this is a bug (and changes the code), or you can explain how the function ZigZagDecode64 is buggy (consistent behaviours on overflow are not bugs, and without optimizations this is what the function does), I will remain of my opinion that this is just a gcc armel bug. Now, given that you reopened the bug, how do we proceed? Do you intend to continue the conversation with upstream about this issue? regards, iustin
signature.asc
Description: Digital signature
