different results depending on compiler optimizations
Transforms bitmaps into vector graphics
Brought to you by:
selinger
Menu
▾
▴
#26 different results depending on compiler optimizations
Hi Peter,
I got a report from a user of dvisvgm saying that one of its test cases fail on 32-bit systems. It turned out that the reason for the failure is different path data created by potrace depending on whether the library was built with or without GCC compiler optimizations. The visual results are still fine, though. Is this "instability" of the results intended behavior and do you know if it can be avoided somehow?
So far, this behavior only ocurred on 32-bit systems.
Hi Martin,
Potrace does use some floating point arithmetic, and due to rounding errors, the results can indeed depend on compiler optimizations (and presumably there might be a difference between 32-bit and 64-bit architectures as well, and between different compilers and OSs). One of the reasons is that processors internally use more than 64 bits to represent floating point numbers. Without compiler optimization, each intermediate result is converted to 64 bits, but with optimizations, the intermediate results are often left in a register with the additional precision.
Gcc (but not clang) has an option -ffloat-store, which turns off this optimization, but it also slows Potrace down.
These small variations are visually imperceptible and are considered as normal behavior for Potrace (i.e., not a bug). The checks in the test suite all have a tolerance built in. However, the tolerances must be fine-tuned from time to time, since compilers keep getting updated which can lead to tests falling just outside of the tolerances that previously worked. The attached patch might fix the problem.
P.S.: another reason the tolerances must be adjusted from time to time is variations in Ghostscript. The test suite uses Ghostscript to render the traced files, and then compares the image to the expected output. Even small changes in Ghostscript's antialiasing routines can therefore require a recalibration of the test suite (not Potrace itself). It doesn't look like this was the problem in your user's case, but I thought I'd mention it since it does affect the reproducibility of the test suite.
Peter, thanks for the prompt reply and the helpful information. The patch indeed fixes the potrace tests. In the test suite of dvisvgm, I currently don't check the similarity of the shapes described by the generated paths but just the command sequences (moveto, curveto etc.) and its parameters as computed by
potrace_trace(). That's obviously too naive an approach. However, the issue has only ocurred since GCC 8. The generated paths now differ quite significantly between optimized and unoptimized code including the number of path segments. I guess I have to improve the tests a bit.Thanks again for the helpful feedback.