similar to: Removing deprecated <ext/hash_set>, <ext/hash_map> and <ext/__hash>

> On Feb 5, 2019, at 23:18, Chandler Carruth <chandlerc at gmail.com> wrote: > > FWIW, I'm pretty sure we still have plenty of code using them. We've not done any analysis to see what timeframe that code could be be updated on -- our focus has been on *adopting* libc++ (and easing that path), not removing the uses of weird things that it also supports. I'll point out

Hi, I saw that Nick Lewycky removed the LLVM portable hash_map and hash_sets. My research group was relying on those classes. What replaces hash_map and hash_set? The LLVM implementation was very convenient as there is no equivalent in STL, and Microsoft's implementation had a different name, as does the C++ 0X implementation. Thanks. Tom Jablin

On 10/3/14 10:16 AM, Dan Albert wrote: >> >> I try to build libc++ and libc++abi for host x86_64(linux) and target >> arm(linux) but fail. >> > > Failing in what way? If this isn't working out of the box, we've done > something wrong. Yeah, it would help to know more specifics about where you're getting stuck. > > jroelofs might know more... For

Hi cschen, It seems that libunwind (the one included in libcxxabi) is mandatory at the moment. Use the second build command instead: $ CROSS_COMPILING=arm ENABLE_LIBUNWIND=1 ./scripts/compile-all.sh Logan On Tue, Oct 7, 2014 at 5:32 PM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > After do "sudo apt-get update", the following are pass. > > Install the

Aaron Gray wrote: > Hi, > > I partly built LLVM on Cygwin yesterday and it was fine as far as it > went. But after doing a svn update today I am getting the following > warning on every compile :- > > > llvm[3]: Compiling LowerAllocations.cpp for Debug build > /usr/src/llvm/lib/Transforms/Utils/LowerAllocations.cpp:1: warning: > -fPIC ignored for

Hi, I partly built LLVM on Cygwin yesterday and it was fine as far as it went. But after doing a svn update today I am getting the following warning on every compile :- llvm[3]: Compiling LowerAllocations.cpp for Debug build /usr/src/llvm/lib/Transforms/Utils/LowerAllocations.cpp:1: warning: -fPIC ignored for target (all code is position independent) This maybe happening on other targets too.

I just landed these patches: commit c55051eea5d3cd57abfd9727f519b670517704d9 Author: Louis Dionne <ldionne at apple.com> Date: Thu Jun 25 12:02:43 2020 -0400 [libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80. commit 33c9c10d183371edc95fa936705bef56f55ab611 Author: Louis Dionne <ldionne at

On 1/19/2013 8:36 PM, Chris Lattner wrote: > > See: > http://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task Were the "small n" characteristics the main motivation? Memory-wise, STL classes allow user-defined allocators, so use of things like memory pools should be relatively straightforward. Just wondering... :) -Krzysztof -- Qualcomm

Hi I'm trying to compile HowToUseJIT.cpp, but it seems that iterator definition is missing: --------------------Configuration: HowToUseJIT - Win32 Debug-------------------- Compiling... HowToUseJIT.cpp c:\sfu\usr\local\src\llvm\include\llvm\adt\ilist(41) : fatal error C1083: Cannot open include file: 'llvm/ADT/iterator': No such file or directory Error executing cl.exe. I've

Hi All, libcxx is fairly well designed to work in a no-exceptions environment, with most of the sources diligently using the _LIBCPP_NO_EXCEPTIONS macro. However, it seems to have bit-rotted a bit and could use some TLC right now. A no-exceptions variety of libcxx would be quite useful when you want to use all of libcxx goodness without the overhead of exceptions (especially in embedded

When I ran configure after updating, I get various errors. First: % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc checking for a BSD-compatible install... /usr/bin/install -c checking build system type... i386-unknown-freebsd5.2.1 checking host system type... i386-unknown-freebsd5.2.1 checking target system type... i386-unknown-freebsd5.2.1 test: Unknown: bad

It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always

On Jan 19, 2013, at 6:00 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/19/2013 7:55 PM, Sean Silva wrote: >> >> Although SmallString is actually pretty inefficient, since it keeps >> the string data separate from the "vector" header. I believe libc++'s >> std::string actually reuses the pointers in the "vector header"

Hi Louis, sorry for bothering you once more about the libcxx test suite! I was wondering whether you could help with some of my problems again. After the recent discussion on the mailing list and your diff, I was able to set up cross-compilation and remote-execution of the libcxx test suite, so thank you for that! We have split up the build of the libraries into different stages, so libcxx,

Jeff Cohen wrote: >But I compiled that under vc7.1 as it was! > > ;-(( Probably is an implicid includes, but I'm using the STLPort standard library for LLVM (because it's not possible to use hash_map and hash_set of microsoft) cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /DHAVE_WINDOWS_H

Hello, I want to use some code written for program dependence graph iteration, but this code uses hash_map (#include "llvm/ADT/hash_map") which i think remove from llvm, does anyone know how can i use hsah_map or simply replace that? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

[Cross-post to llvm-dev to make sure everybody relevant sees this] Hi, I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the

I finally managed to compile a working fibonacci example (using the interpreter, I'm still working on porting the x86 backend). The final problem was that I couldn't find a way to force the linker to include the Dominators.obj file since there were no references to it. There is an option to the linker to stop it from stripping unreferenced code, but it still doesn't pull the object

On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > Jeff Cohen wrote: > > >But I compiled that under vc7.1 as it was! > > > > > ;-(( > > Probably is an implicid includes, but I'm using the STLPort standard > library for LLVM (because it's not possible to use hash_map and hash_set > of microsoft) std::remove is in <algorithm> --