#217: Nasty bug in mln::data::impl::in memcpy_ with g++ 4.2 on Debian GNU/Linux on IA-32 -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: closed Priority: critical | Milestone: Olena 1.1 Component: Milena | Version: 1.0 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by levill_r): * status: new => closed * resolution: => fixed Old description:

Running the following test exhibits this issue: {{{ make -C milena/apps/graph-morpho CXX="ccache g++-4.2" checkTESTS=samples- image2d TESTS_ENVIRONMENT="valgrind" }}}

This seems to be a bug (or a weird implementation-defined behavior) in Debian's `g++` 4.2 on IA-32, due to some strict-aliasing rule not respected in Milena's code. I added a `#warning` in `memcpy_.hh` in r4608.

But the thing is, `g++` 4.2 is the main compiler in Debian GNU/Linux 5.0, which is used on most GCC-based Olena buildbots, meaning we won't get a successful build on these hosts until we circumvent this bug. That's bad.

New description: Running the following test exhibits this issue: {{{ make -C milena/apps/graph-morpho CXX="ccache g++-4.2" check \ TESTS=samples-image2d TESTS_ENVIRONMENT="valgrind" }}} This seems to be a bug (or a weird implementation-defined behavior) in Debian's `g++` 4.2 on IA-32, due to some strict-aliasing rule not respected in Milena's code. I added a `#warning` in `memcpy_.hh` in r4608. But the thing is, `g++` 4.2 is the main compiler in Debian GNU/Linux 5.0, which is used on most GCC-based Olena buildbots, meaning we won't get a successful build on these hosts until we circumvent this bug. That's bad. -- Comment: Workaround applied in branch `fix-g++-4.2-strict-aliasing`, merged into `next`. -- Ticket URL: <https://trac.lrde.org/olena/ticket/217#comment:1> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.