What are the minimum required gcc + clang versions for this change. HIP nightly tests are failing to build after the commit to drop c++03 support
https://github.com/eigenteam/eigen-git-mirror/commit/c345a995a9d2c17ac8c7d07c71afe77fa6f30d79 There seems to be more than cause for the build failure. One of the failures is : --------------------------------------- In file included from /home/rocm-user/eigen/unsupported/test/ cxx11_tensor_argmax_gpu.cu:16: In file included from /home/rocm-user/eigen/unsupported/Eigen/CXX11/Tensor:34: /home/rocm-user/eigen/unsupported/Eigen/CXX11/src/util/CXX11Meta.h:45:7: error: no matching constructor for initialization of 'std::array<long, 4UL>' : Base{v1, v2, v3, v4} { ^ ~~~~~~~~~~~~~~~~ /home/rocm-user/eigen/unsupported/test/cxx11_tensor_argmax_gpu.cu:110:82: note: in instantiation of member function 'Eigen::array<long, 4>::array' requested here Eigen::TensorMap<Eigen::Tensor<float, 4, DataLayout>, Aligned > gpu_in(d_in, Eigen::array<DenseIndex, 4>(2, 3, 5, 7)); ^ /home/rocm-user/eigen/unsupported/test/cxx11_tensor_argmax_gpu.cu:249:18: note: in instantiation of function template specialization 'test_gpu_argmax_dim<1>' requested here CALL_SUBTEST_2(test_gpu_argmax_dim<RowMajor>()); ^ /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/array:89:12: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 4 were provided struct array ^ /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/array:89:12: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 4 were provided /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/array:89:12: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 4 were provided /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/array:89:12: note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 4 were provided / -------------------------------------- Anyone else running into this? Also the regression dashboard ( http://manao.inria.fr/CDash/index.php?project=Eigen) seems to be down. I get the following error when I try to access it *Fatal error*: Uncaught Error: Call to a member function quote() on bool in /mnt/www/html/CDash2/include/pdo.php:341 Stack trace: #0 /mnt/www/html/CDash2/include/pdo.php(363): pdo_real_escape_string('', NULL) #1 /mnt/www/html/CDash2/public/ajax/getfeed.php(26): pdo_real_escape_numeric('') #2 {main} thrown in */mnt/www/html/CDash2/include/pdo.php* on line *341* deven On Mon, Oct 21, 2019 at 12:56 PM Eugene Zhulenev <[email protected]> wrote: > I think that transpose for small sizes should be fixed at head already. > > On Mon, Oct 21, 2019 at 9:34 AM William Tambellini <[email protected]> > wrote: > >> Hi Rasmus, >> Thanks. If I could help (test, profil, ...), please email me. If I >> remember right, as today, these ops are still faster via Matrix vs Tensor: >> - reductions >> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1614 >> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1628 >> - gemv >> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1648 >> - transpose >> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1627 >> Kind >> W. >> >> William Tambellini | Senior Software Developer | SDL Los Angeles | >> [email protected] >> http://www.sdl.com >> <http://bit.ly/2LB1qRN> >> *Share yourfeedback with us* <https://www.surveymonkey.com/r/PYF190816> >> >> ------------------------------ >> *From:* Rasmus Munk Larsen <[email protected]> >> *Sent:* Monday, October 21, 2019 9:04 AM >> *To:* eigen <[email protected]> >> *Subject:* Re: [eigen] Should we require c++11 for Eigen tensor >> >> Hi William, >> >> Eugene Zhulenev's work on the new BlockV2 evaluation framework, should >> make it a lot easier to address some of the performance issues you are >> seeing, including adding block evaluation for concat. So far, TensorFlow as >> been using a custom concat operation that does not use Eigen, so we never >> thought to address this. But if we can make it fast in Eigen and get rid of >> custom code for this op, we will. >> >> Rasmus >> >> On Sat, Oct 19, 2019 at 6:52 PM William Tambellini <[email protected]> >> wrote: >> >> Ok for me. Specially if that could ease to resolve the speed issues of >> the Tensor module. >> Kind >> WT. >> >> <http://bit.ly/2LB1qRN> >> *Share your feedback with us* <https://www.surveymonkey.com/r/PYF190816> >> >> ------------------------------ >> *From:* Christoph Hertzberg <[email protected]> >> *Sent:* Friday, October 18, 2019 10:03 AM >> *To:* [email protected] <[email protected]> >> *Subject:* Re: [eigen] Should we require c++11 for Eigen tensor >> >> Hi! >> >> I think some time ago there was some opposition against that step -- in >> fact, originally C++03 was only introduced after the first versions of >> the Tensor module. >> >> I can't find a reference to that discussion at the moment, I think it >> concerned supporting Tensor for some GPU architecture. But this was a >> few years ago, and compilers likely evolved since then. >> >> So unless there is an outcry on this list, I'm not against dropping >> C++03 support of the Tensor module. >> >> >> For transitioning it would of course be nice to have a clear "latest >> working" version which still supports C++03, one possibility would be to >> make that with the 3.4 release. OTOH, this will just complicate >> maintenance and Tensors are still "unsupported" for a reason (e.g., not >> having to spend unnecessary time to support them ...) >> >> So just making a clear cut before 3.4 sounds actually better -- this >> will also simplify to maintain the upcoming 3.4 and master versions in >> parallel (I guess the 3.3.x version of the Tensor module has barely been >> touched in recent years). >> >> >> Cheers, >> Christoph >> >> On 18/10/2019 18.46, Rasmus Munk Larsen wrote: >> > Dear Eigen tensor users, >> > >> > Today, various c++11 features are in use in many parts of Eigen tensor, >> > while other parts compile with c++03 without warnings. This division is >> > rather arbitrary and primarily dictated by what parts of the code gets >> > compiled for the subset of tests that are enabled in c++03 mode: >> > >> > >> https://bitbucket.org/eigen/eigen/src/default/unsupported/test/CMakeLists.txt#lines-112 >> > >> > A larger set of tests covering the majority of the code base are only >> > compiled in c++11 mode: >> > >> https://bitbucket.org/eigen/eigen/src/c4368f48fef3737ef5a48604cfc63ce946b68616/unsupported/test/CMakeLists.txt#lines-179 >> > >> > I don't think a user can realistically use Eigen tensor and avoid the >> c++11 >> > parts of the code. Therefore I would propose that we stop pretending >> that >> > Eigen tensor supports c++03 and simply guard all the code with >> > EIGEN_HAS_CXX11 or similar. This will then allow us to start cleaning up >> > the code. >> > >> > Please let me know if you have any objections to this. >> > >> > Best, >> > Rasmus >> > >> >> -- >> Dr.-Ing. Christoph Hertzberg >> >> Besuchsadresse der Nebengeschäftsstelle: >> DFKI GmbH >> Robotics Innovation Center >> Robert-Hooke-Straße 5 >> 28359 Bremen, Germany >> >> Postadresse der Hauptgeschäftsstelle Standort Bremen: >> DFKI GmbH >> Robotics Innovation Center >> Robert-Hooke-Straße 1 >> 28359 Bremen, Germany >> >> Tel.: +49 421 178 45-4021 <+49%20421%20178454021> >> Zentrale: +49 421 178 45-0 >> E-Mail: [email protected] >> >> Weitere Informationen: http://www.dfki.de/robotik >> ------------------------------------------------------------- >> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH >> Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany >> >> Geschäftsführung: >> Prof. Dr. Jana Koehler (Vorsitzende) >> Dr. Walter Olthoff >> >> Vorsitzender des Aufsichtsrats: >> Prof. Dr. h.c. Hans A. Aukes >> Amtsgericht Kaiserslautern, HRB 2313 >> ------------------------------------------------------------- >> >> >> >> >> >> Click here >> <https://www.mailcontrol.com/sr/ELeTgw_9Q__GX2PQPOmvUizKrmxxhcEGMKpSJFYoHVK-Z8uO7HUp62mTmkAYMGtVR8AB6krnmzENCU1_U1Tbvw==> >> to report this email as spam. >> >
