On Wed, 11 Mar 2020 at 01:02, Mateusz Loskot
Over the last few months, intermittently I've been chasing a peculiar bug that has been revealing itself in failing checksum tests in GIL's test/legacy/image.cpp [1] since we started testing GIL with MSVC++ (VS2017, VS2019) with
b2 toolset=msvc variant=release address-model=64 [...] auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value ++loc.x(); // INCREMENT X FIRST --loc.y(); }
Ha! I've just noticed failures between VS 2017 and 2019 are a bit different, still for bgr121_image_t though, still for 64-bit optimised builds only: VS2017 build fails at bgr121_views_90cw test case: ====== BEGIN OUTPUT ===== ... checking checksum for bgr121_basic_red_x (crc=7f6e24e7) Checking checksum for bgr121_basic_white_x (crc=e4aaa1d3) Checking checksum for bgr121_views_original (crc=7e5bb87d) Checking checksum for bgr121_views_cropped (crc=43305e15) Checking checksum for bgr121_views_gray8 (crc=bbabe219) Checking checksum for bgr121_views_my_gray8 (crc=3086d22f) Checking checksum for bgr121_views_transpose (crc=da2ff80) Checking checksum for bgr121_views_rot180 (crc=68f37202) Checksum error in bgr121_views_90cw (crc=8ffd852b != 8565efd8) Unknown exception ====== END OUTPUT = VS2019 build fails much sooner: ====== BEGIN OUTPUT ===== ... Checksum error in bgr121_basic_red_x (crc=85c86c53 != 7f6e24e7) Unknown exception ====== END OUTPUT = Clearly, there is something fishy going on near the MSVC++ optimisation. Looking at the C++ code, I'm getting very suspicious about what is going on in the decrement operator, or boost::iterator_facade implementor. I have not compared assembly for the minimal_test.cpp cases. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net