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: Ungermann, Jörn (j.ungermann_at_[hidden])
Date: 2012-09-05 04:06:26

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.

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.

Kind regards,
Jörn

> -----Original Message-----
> From: ublas-bounces_at_[hidden] [mailto:ublas-
> bounces_at_[hidden]] On Behalf Of sguazt
> Sent: Dienstag, 28. August 2012 22:26
> To: ublas mailing list
> Subject: Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was:
> patches for #7297, #7296, #6514, #6511 on trunk - please verify)
> 
> On Tue, Aug 28, 2012 at 9:46 PM, Thomas Klimpel
> <Thomas.Klimpel_at_[hidden]> wrote:
> > Gunter Winkler wrote:
> >> Looks like this hack does not work with gcc 4.7 any more. Maybe we
> >> can improve coordinate_matrix::sort() somehow to use the
> >> zip_iterator. (see
> >> storage_sparse.hpp:4396)
> >
> > My conclusion in
> <http://lists.boost.org/MailArchives/ublas/2011/12/5123.php> was that
> we need an implementation of "std::inplace_merge" guaranteed to accept
> our iterators. Basically any existing implementation could be used, as
> long as the licensing conditions allow this.
> >
> > As a side note, inplace_merge is cheating anyway, allocates temporary
> memory, and will only fall back to a true inplace_merge if this fails.
> >
> > Regards,
> > Thomas
> 
> Hi,
> 
> After having done "svn update" (rev 80290), I've compiled the following
> tests with GCC 4.7.0:
>         begin_end
>         comp_mat_erase
>         concepts
>         num_columns
>         num_rows
>         placement_new
>         size
>         sparse_view_test
>         test_assignment
>         test_complex_norms
>         test_coordinate_matrix_sort
>         test_inplace_solve
>         test_lu
>         test_triangular
>         triangular_access
>         triangular_layout
> 
> All test succeeded except:
>         test_assignment
>         test_coordinate_matrix_sort  (as expected)
>         test_inplace_solve
> 
> Cheers,
> 
> -- Marco
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: j.ungermann_at_[hidden]