On 3 Aug 2003, Ronald Bultje wrote: > Hey Trent, > > On Sun, 2003-08-03 at 00:09, Trent Piepho wrote: > > I don't think "fixes" is really the correct term, more appropriate would be > > "masks". If the code fails with -O3, then there is either A) a bug in the > > code, or B) a bug in the optimizer. Using a different optimization level > > level doesn't fix either one. > > You're right, sorry for the word confusion. > > Since most developers don't see the problem, and since nobody sees it at > "standard test levels" (-O0), I'd assume it's a compiler bug. Code bugs > would show up specifically at -O0.
Not really, there are plenty of bugs that don't show up at lower optimizations. One bug that I recently fixed was in some FORTRAN code that failed when compiled with optimizations. Turns out that someone had declared a library routine as subroutine when it was really a function. In C terms, a library function returned double, but prototype in the include file said it was void. This meant that the the compiler didn't pop the return value off the floating point stack after the function returned. Without optimizations, this didn't happen to cause a noticeable problem, but that's just luck. With optimizations, multiple simple expressions got combined into one more complex, and floating point stack intensive, expression. This then caused the floating point stack to overflow, resulting in random corruption of calculations that had nothing what so ever to do with the real bug. The source that needed to be compiled without optimizations didn't even have a bug! The incorrect prototype was in a different source file that could be compiled with or without optimizations. If the compiler didn't have a special floating point stack checker as a debug option, something like this would next to impossible to fix. There's a real example of a bug that only appeared with optimizations, but was a bug in the code none the less. It might seem that jpeg-mmx is fixed with -O2, but the problem is probably still there. You might change something in totally unrelated code in AC3 audio decoding that causes the compiler to use one more floating point register, and then it comes back to bite you even with -O2. Worse yet, the guy working on AC3 will have no clue that he's triggered a bug in jpeg-mmx, and (sadly, I speak from experience here) spend days trying to figure out why the hell his code isn't working, going over every line again and again trying to find a bug that isn't there. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
