On Fri, Oct 14, 2016 at 11:54 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi Michael, > > On Fri, Oct 14, 2016 at 2:31 PM, Michael Niedermayer <mich...@niedermayer.cc >> wrote: > >> On Fri, Oct 14, 2016 at 08:29:37PM +0200, Michael Niedermayer wrote: >> > On Fri, Oct 14, 2016 at 11:09:30AM -0700, James Zern wrote: >> > > Ronald, >> > > >> > > On Fri, Oct 14, 2016 at 10:01 AM, Ronald S. Bultje <rsbul...@gmail.com> >> wrote: >> > > > This is intended to workaround bug "665 Integer Divide Instruction >> May >> > > > Cause Unpredictable Behavior" on some early AMD CPUs, which causes a >> > > > div-by-zero in this codepath, such as reported in Mozilla bug >> #1293996. >> > > > >> > > > Note that this isn't guaranteed to fix the bug, since a compiler is >> free >> > > > to reorder instructions that don't depend on each other. However, it >> > > > appears to fix the bug in Firefox, and a similar patch was applied to >> > > > libvpx also (see Chrome bug #599899). >> > > > >> > > >> > > I recently made a few additional changes as this regressed in chrome >> > > [1][2], but just like this change there's no guarantee it won't occur >> > > again. >> > >> > maybe you can use empty "asm volatile(:::"memory")" statments to >> > prevent unwanted instruction reordering by the compiler >> > never tried something like this so dunno, also it would be specific >> > to gcc compatible compilers but should not be architecture specific >> >> thinking again, why dont you write the function in asm for x86 ? >> this would take the compiler out of the equation > > > I think the primary reason is that "this seems to work". Don't forget that > the bug is in the hardware, not in the code, so I don't want to make the > code needlessly (well... maybe that's debatable) complicated for a problem > that isn't really ours... > > But I guess I'm open to hearing everyone else's opinion on this - if people > want me to make the workaround more persistent I can work on that. >
That ended up being my view mostly due to the fact that I didn't have access to the hardware. Even with assembly there is a timing/scheduling element, so it may be less fragile, but I think the bug could still occur. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel