On 19/10/16 18:35, Matt Turner wrote:
On Wed, Oct 19, 2016 at 9:54 AM, Marek Olšák <[email protected]> wrote:
On Wed, Oct 19, 2016 at 6:06 PM, Emil Velikov <[email protected]> wrote:
On 19 October 2016 at 15:55, Marek Olšák <[email protected]> wrote:
On Wed, Oct 19, 2016 at 12:47 PM, Emil Velikov <[email protected]> wrote:
On 19 October 2016 at 11:35, Grigori Goronzy <[email protected]> wrote:
On 2016-10-04 12:32, Emil Velikov wrote:
On 2 October 2016 at 14:17, Axel Davy <[email protected]> wrote:
I'd prefer myself Oct 14, because we have a lot of patches for nine, and
they deserve more cleaning and testing, but if it's Oct 7, we'll try be
on
time.
14th it is. As mentioned before: _don't_ wait for the last week to get
things merged. Once you're reasonably happy just send the new work
review and commit it.
Same applies for bugfixes :-)
What happened to these plans? It is the October 19th already. Nine fixes
have trickled into Mesa and radv was merged also. What's the holdup?
I've spent a (bit too many) days on trying to get things working with LLVM 3.9.
So on my end, I'll consider it broken and let the LLVM wizards take care of it.
Is the LLVM 3.9 issue related to radeonsi?
Plain gallium, as per below.
../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o):
In function
`llvm::RTDyldMemoryManager::getSymbolAddress(std::__cxx11::basic_string<char,
std::char_tra
its<char>, std::allocator<char> > const&)':
/usr/local/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:87:
undefined reference to
`llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<ch
ar, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:87:
undefined reference to
`llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<ch
ar, std::char_traits<char>, std::allocator<char> > const&)'
An identical symbol with different signature is provided by the static
lib and header:
$ objdump -CtT libLLVMRuntimeDyld.a | grep
"llvm::RTDyldMemoryManager::getSymbolAddressInProcess"
... 0000000000000149
llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::string
const&)
$ grep getSymbolAddressInProcess .../include/
RTDyldMemoryManager.h: static uint64_t
getSymbolAddressInProcess(const std::string &Name);
And in the LLVM 3.8 case (which works like a charm):
$ objdump -CtT libLLVMRuntimeDyld.a | grep
"llvm::RTDyldMemoryManager::getSymbolAddressInProcess"
...0000000000000181
llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
$ grep getSymbolAddressInProcess .../include/
RTDyldMemoryManager.h: static uint64_t
getSymbolAddressInProcess(const std::string &Name);
It smells like partial/incomplete build with the C++11 ABI, but trying
to untangle the lot is quite time consuming.
I admit I have no idea what all that means.
This looks like C++ ABI mismatch. See
https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ for
details.
Recompile LLVM and Mesa with the same g++.
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Perhaps the problem is that LLVM 3.9 is built with -std=c++11:
$ llvm-config-3.9 --cxxflags
-I/usr/lib/llvm-3.9/include -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections
-fdata-sections -O2 -g -DNDEBUG -fno-exceptions -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
I know we've been cherrypicking which bits of llvm-config's output we
want. Perhaps we need to make sure we pick --std=c++11.
But this also implies that *all* Mesa needs to build reliably with
--std=c++11. I recall there were problems some time ago when OpenSWR
wanted to use c++11. So it might not be trivial.
I also looked up into replace our
lp_build_create_jit_compiler_for_module with some standard LLVM-C
binding entry point. But LLVMCreateMCJITCompilerForModule doesn't seem
to do nowhere near the stuff we do...
Jose
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
