Closed Hitman4Reason closed 1 week ago
@Hitman4Reason, could you please verify whether the problem persists after removing the /home/goncalocosta/sycl_workspace/llvm/build/_deps/unified-runtime-src/ directory?
@bader After which I just run python3 $DPCPP_HOME/llvm/buildbot/compile.py again?
Right, but I just checked the full log and I see that you are doing the build from the scratch, so it won't help.
It looks like libstdc++ is missing iterator erase( const_iterator position );
for std::basic_string<CharT,Traits,Allocator>
. Which is unexpected with GCC 11.2.1.
/home/goncalocosta/sycl_workspace/llvm/build/_deps/unified-runtime-src/source/common/ur_util.hpp: In function ‘std::optional<std::vector<std::basic_string<char> > > getenv_to_vec(const char*)’:
/home/goncalocosta/sycl_workspace/llvm/build/_deps/unified-runtime-src/source/common/ur_util.hpp:171:24: error: no matching function for call to ‘std::basic_string<char>::erase(std::basic_string<char>::const_iterator)’
171 | value.erase(value.cbegin());
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~
In file included from /opt/rh/devtoolset-11/root/usr/include/c++/11/string:55,
from /opt/rh/devtoolset-11/root/usr/include/c++/11/bits/locale_classes.h:40,
from /opt/rh/devtoolset-11/root/usr/include/c++/11/bits/ios_base.h:41,
from /opt/rh/devtoolset-11/root/usr/include/c++/11/ios:42,
from /opt/rh/devtoolset-11/root/usr/include/c++/11/ostream:38,
from /opt/rh/devtoolset-11/root/usr/include/c++/11/iostream:39,
from /home/goncalocosta/sycl_workspace/llvm/build/_deps/unified-runtime-src/source/ur/ur.hpp:17,
from /home/goncalocosta/sycl_workspace/llvm/sycl/plugins/unified_runtime/pi2ur.hpp:14,
from /home/goncalocosta/sycl_workspace/llvm/sycl/plugins/unified_runtime/pi_unified_runtime.cpp:12:
/opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:4759:7: note: candidate: ‘std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::erase(std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]’
4759 | erase(size_type __pos = 0, size_type __n = npos)
| ^~~~~
/opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:4759:23: note: no known conversion for argument 1 from ‘std::basic_string<char>::const_iterator’ to ‘std::basic_string<char>::size_type’ {aka ‘long unsigned int’}
4759 | erase(size_type __pos = 0, size_type __n = npos)
| ~~~~~~~~~~^~~~~~~~~
/opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:4775:7: note: candidate: ‘std::basic_string<_CharT, _Traits, _Alloc>::iterator std::basic_string<_CharT, _Traits, _Alloc>::erase(std::basic_string<_CharT, _Traits, _Alloc>::iterator) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::basic_string<_CharT, _Traits, _Alloc>::iterator = std::basic_string<char>::iterator]’
4775 | erase(iterator __position)
| ^~~~~
/opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:4775:22: note: no known conversion for argument 1 from ‘__normal_iterator<const char*,[...]>’ to ‘__normal_iterator<char*,[...]>’
4775 | erase(iterator __position)
| ~~~~~~~~~^~~~~~~~~~
/opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:4795:7: note: candidate: ‘std::basic_string<_CharT, _Traits, _Alloc>::iterator std::basic_string<_CharT, _Traits, _Alloc>::erase(std::basic_string<_CharT, _Traits, _Alloc>::iterator, std::basic_string<_CharT, _Traits, _Alloc>::iterator) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::basic_string<_CharT, _Traits, _Alloc>::iterator = std::basic_string<char>::iterator]’
4795 | erase(iterator __first, iterator __last);
| ^~~~~
/opt/rh/devtoolset-11/root/usr/include/c++/11/bits/basic_string.h:4795:7: note: candidate expects 2 arguments, 1 provided
@intel/unified-runtime-reviewers, any clues?
Environment
OS: Linux GPU: RTX 3070
I don't think we have enough information about the operating system being used here to do a proper diagnosis.
$ gcc --version gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) Copyright (C) 2021 Free Software Foundation, Inc.
The gcc version output suggests this is failing on Red Hat but without knowing what version of Red Hat it's difficult to say. This could be a newer gcc package on an older, possibly unsupported, version of Red Hat, for example.
I would also like to know the glibc version in use.
Could you add this info please @Hitman4Reason?
Sorry here it is: CentOS Linux release 7.3.1611 (Core)
$ ldd --version ldd (GNU libc) 2.17 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.
Anything else I should provide?
The libstdc++ version would also be useful now I think of it.
Was a bit confused on how to do that but here is what I got.
$ /sbin/ldconfig -p | grep stdc++ libstdc++.so.6 (libc6,x86-64) => /lib64/libstdc++.so.6 libstdc++.so.6 (libc6) => /lib/libstdc++.so.6 libstdc++.so.5 (libc6,x86-64) => /lib64/libstdc++.so.5 libstdc++.so.5 (libc6) => /lib/libstdc++.so.5
What's the output of this?
$ strings /lib64/libstdc++.so.6 | grep LIBCXX
@kbenzie $ strings /lib64/libstdc++.so.6 | grep LIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_DEBUG_MESSAGE_LENGTH
Seems like that's a rather old version (gcc 4.8.3) of libstdc++ which doesn't fully support C++17. Looking at the compile errors though, it appears you should be using the libstdc++ headers shipped with gcc 11 which should fully support C++17.
The code in question here is not doing anything wrong that I can tell. There is a const_iterator
overload for std::string::erase and that's what is gets returned from std::string::cbegin
/std::string::cend
being passed in for both of these calls.
std::string value;
...
value.erase(value.cbegin());
value.erase(value.cend() - 1);
In general, I don't believe RedHat 7 (and thus CentOS 7) is a supported platform any longer.
the problem seems to be with the OS. Works on other systems so will close this. Thanks
Describe the bug
Am unable to compile the most recent commits with CUDA backend. Have been trying for the past week. Was however able to install the release: https://github.com/intel/llvm/releases/tag/2022-12 with CUDA backend.
All the recent commits I tried to install failed on step 3006/3886. Any advice on how to get it to compile would be apreciated. I do not know if its an issue with my process or if the most recent commits aren't supposed to be working with "--cuda" configure flag.
Thanks in advance
To reproduce
The console output can be accessed here:
output.txt
The whole output is on the txt file but regardless, "python3 $DPCPP_HOME/llvm/buildbot/compile.py" output the following:
Environment
OS: Linux CentOS Linux release 7.3.1611 (Core) GPU: RTX 3080
Additional context
No response