[gil] Locator bug in MSVC release builds
Hi all, there is this nagging bug (#49) with boost::gil which I have a hard time figuring out. Please consider the following code: #define _CRT_SECURE_NO_WARNINGS 1 #include <boost/gil/gil_all.hpp> #include <boost/gil/extension/io/bmp_all.hpp> using namespace boost::gil; int main() { using ref_t = const bit_aligned_pixel_reference<boost::uint8_t, boost::mpl::vector3_c<int, 1, 2, 1>, bgr_layout_t, true>; using ptr_t = bit_aligned_pixel_iterator<ref_t>; using pixel_t = std::iterator_traits<ptr_t>::value_type; using bgr121_image_t = image<ref_t, false>; ////////////////////// // works ////////////////////// { bgr121_image_t a(10, 10); fill_pixels(view(a), pixel_t(0, 0, 1)); auto loc = view(a).xy_at(0, 0); for (int y = 0; y < view(a).height(); ++y) { *loc = pixel_t(1, 0, 0); ++loc.x(); ++loc.y(); } auto v = color_converted_view<rgb8_pixel_t>(view(a)); write_view("a.bmp", v, bmp_tag()); } ////////////////////// // doesn't work ////////////////////// { bgr121_image_t b(10, 10); fill_pixels(view(b), pixel_t(0, 0, 1)); auto loc = view(b).xy_at(0, view(b).height() - 1); for (int y = 0; y < view(b).height(); ++y) { *loc = pixel_t(1, 0, 0); ++loc.x(); --loc.y(); } auto v = color_converted_view<rgb8_pixel_t>(view(b)); write_view("b.bmp", v, bmp_tag()); } } When running with VS 2017 all is working in Debug but with Release the second image is incorrect. The bug should be in the locator code. Anyone has an idea what is going wrong or what else I should try? Thanks, Christian
On 31 March 2018 at 23:48, Christian Henning via Boost <boost@lists.boost.org> wrote:
Hi all,
there is this nagging bug (#49) with boost::gil which I have a hard time figuring out.
[...] When running with VS 2017 all is working in Debug but with Release the second image is incorrect.
For both, 32 and 64 bit target? I can only reproduce the bug using VS 2017 build for 64-bit in Release configuration. IMHO, the bug seems related to https://github.com/boostorg/gil/issues/51 which can be reproduced building b2 variant=release with GCC 5.4.1 and clang 5.0 but it can not be reproduced with GCC 7.2 and clang 4.2.1 At least that is what I have tried (see comments for #51 linked above). Best regards -- Mateusz Loskot, http://mateusz.loskot.net
On 1 April 2018 at 00:21, Christian Henning <chhenning@gmail.com> wrote:
For both, 32 and 64 bit target?
Yes! Only with 64bit.
The GCC and clang failures mentioned earlier are also for 64-bit. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
participants (2)
-
Christian Henning
-
Mateusz Loskot