#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.