On Wed, Oct 23, 2019 at 10:39 AM Deven Desai <deven.desai.amd@xxxxxxxxx> wrote:
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 supportThere 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 341devenOn Mon, Oct 21, 2019 at 12:56 PM Eugene Zhulenev <ezhulenev@xxxxxxxxxx> 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 <wtambellini@xxxxxxx> 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- gemvW.William Tambellini | Senior Software Developer | SDL Los Angeles | wtambellini@xxxxxxx
From: Rasmus Munk Larsen <rmlarsen@xxxxxxxxxx>
Sent: Monday, October 21, 2019 9:04 AM
To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [eigen] Should we require c++11 for Eigen tensorHi 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 <wtambellini@xxxxxxx> wrote:
Ok for me. Specially if that could ease to resolve the speed issues of the Tensor module.KindWT.
From: Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, October 18, 2019 10:03 AM
To: eigen@xxxxxxxxxxxxxxxxxxx <eigen@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [eigen] Should we require c++11 for Eigen tensorHi!
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
Zentrale: +49 421 178 45-0
E-Mail: christoph.hertzberg@xxxxxxx
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 to report this email as spam.
