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

Hi,

test_inplace_solve fails mostly, because it uses a coordinate_matrix. *Some*
errors are be unrelated, though.
I had a closer look at the failures:

a) The includes in lines 10-12 of test_inplace_solve.cc I supplied are
unnecessary and break on some (for me exotic) systems. (They were originally
included for timing and I forgot to remove them. Sorry).
b) The const int n = 10; in line 87 is superfluous, which produces some
warnings.
c) The vacpp testcases fail, because it cannot instantiate a
mapped_vector_of_vector on that system. There does not seem to be any other
testcase for this type. std::map seems to not provide a data_value_type
member type.
One might want to add a simple testcase using a mapped_vector_of_vector for
verification of this hypothesis before proceeding. I have not access to the
vacpp compiler.
d) Some systems fail, because there is no triangular.hpp.new. I cannot
fathom, how this is correct on some systems, but not on others. The original
testcase provided by me had this error, but according to the bug entry, it
was fixed, so it should be OK on all of them...
d) The remaining errors fail due to the coordinate_matrix problem.

Sorry for the inconvenience,
Jörn


> -----Original Message-----
> From: [email protected] [mailto:ublas-
> [email protected]] 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
> <[email protected]> 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
> [email protected]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]

_______________________________________________
ublas mailing list
[email protected]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [email protected]