Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)

Subject: Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)
From: sguazt (marco.guazzone_at_[hidden])
Date: 2012-09-06 05:15:56

On Wed, Sep 5, 2012 at 10:06 AM, "Ungermann, Jörn"
<j.ungermann_at_[hidden]> wrote:
> Hello,
>
> I do not think that this qualifies as a valid fix, but for gcc 4.4 and gcc
> 4.7 the following hack worked for us. Perhaps one could do a gcc version
> specific #ifdef. Might be preferable to not working at all.
>
> This change in matrix_sparse.hpp
> //                std::inplace_merge (ita.begin (), iunsorted, ita.end ());
>                 if (ita.begin() != iunsorted && iunsorted != ita.end ()) {
>                     std::__merge_without_buffer(ita.begin (), iunsorted,
> ita.end (),
>                                                 std::distance(iunsorted,
> ita.end ()));
>                                                 std::distance(iunsorted,
> ita.end ()));
>                 }
> and a corresponding one in vector_sparse.hpp seems to work quite well for
> the time being. Not really future-proof, though.
>

Hello,

I've tried to put this hack in matrix_sparse and compiled with GCC
4.7. It works. Just for info, above there are too much ";" ;)
The right version is:
                if (ita.begin() != iunsorted && iunsorted != ita.end ()) {
                    std::__merge_without_buffer(ita.begin (),
iunsorted, ita.end (), std::distance(iunsorted, ita.end ()),
std::distance(iunsorted, ita.end ()));
                }

For what concerns the use of an #ifdef for GCC, I agree with you that
it is better to have something that works than to have not. I'm just
curious if this is a problem only concerning GCC.
I usually compile with "--Wall --ansi --pendantic" flags in order to
make sure that the written code is as much standard as possible. So if
the problem is only related to GCC, does this mean that GCC is not
fully compliant with standard C++ (actually with C++98)?

> Just replacing the functionality of merge_without_buffer with a dedicated
> function operating on the coordinate_matrix arrays would also be not too
> difficult.
> I guess the algorithm used by the STL is not protected? I could explain the
> algorithm to my collegue and he can implement it.
>

Unfortunately I don't know this part of uBLAS so I can't help you. :(

After this problem has been fixed, the other remaining failing test is
test_assignment.
Anyone, any idea?

Best,

-- Marco