search for: hash_map

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201010...

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

Hi, Libc++ has been shipping the <ext/hash_set>, <ext/hash_map> and <ext/__hash> headers for a while and they are deprecated. Those headers contain data structures like __gnu_cxx::hash_map that have replacements like std::unordered_map. I would like to remove those headers. I've put up a patch for review but I won't commit it until we have a s...

I have spent some time examining the llvm code now, and it seems most of the hash_maps are keyed with pointers, and a few with ints. There is also one place where the keys are std::string. All these are unproblematic with the Visual Studio std_ext::hash_map since it provides hash_value functions for all these types (note, it hashes char * as pointers, not as strings - but char *...

...ink that's the question, since the same could be said of almost any removal of deprecated API. The cost of keeping code around is usually not that large if you decide not to maintain it anymore. But that's called code rot, and it's generally not a good idea to accumulate too much of it. hash_map probably has bugs that we haven't and won't fix, etc. Libc++ implements a Standard. __gnu_cxx::hash_map is not part of (any version of) that Standard, and so it does not belong in libc++. When I remove or rename some internal function inside libc++ that uses reserved identifiers, I don'...

...Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet), Microsoft decided to move it from the std namespace to the stdext namespace. Use of std::hash_map is therefore deprecated. Similar shenanigans have been committed by gcc from one version to another. I see where this is handled (llvm/ADT/hash_map), but it isn...

So, after digging around in the old llvm/ADT/hash_map, I think I discovered the problem. Now, if you want to include llvm/ADT/HashExtras.h, you have to include the hash_map h file from your system (ext/hash_map in my case) and define HASH_NAMESPACE, before you include llvm/ADT/HashExtras. It might be good to include some documentation about tha...

...eing built twice > as a result). > > * Fix a class/struct inconsistency. > > * Remove unneeded #includes from win32 fSystem files. > Thanks for the excellent patches. All commited. > I've also determined why VC++ complains about deprecated destructors > when using hash_map. Because it's not ANSI (yet), Microsoft decided to > move it from the std namespace to the stdext namespace. Use of > std::hash_map is therefore deprecated. Similar shenanigans have been > committed by gcc from one version to another. I see where this is > handled (llvm/ADT/hash...

>>I've also determined why VC++ complains about deprecated destructors >>when using hash_map. Because it's not ANSI (yet), Microsoft decided to >>move it from the std namespace to the stdext namespace. Use of >>std::hash_map is therefore deprecated. Similar shenanigans have been >>committed by gcc from one version to another. I see where this is >>handled (l...

I am trying to upgrade my code to use the latest version of llvm from svn. Whenever I include "llvm/ADT/HashExtras.h", I get error messages like the following. Does anyone know what is going on? Thanks for any help. llvm[1]: Compiling Aux.cpp for Debug build (PIC) In file included from /home/lefever/work/memrep/src/compiler/include/Aux.h:4, from Aux.cpp:1:

...references. In the end I opted for the ugly IncludeFile() trick which is used elsewhere in the code, I include a patch with this mail. If someone has any better suggestions for how to fix this, I am all ears... The other areas which have to be resolved is the struct/class debacle and also the hash_map usage (I am using the Visual Studio STL library) -- my fix for the hash_map thing is too ugly to go in, so I won't even bother to submit a patch. Unfortunately I have to link LLVM with our own app which is using the MS STL, so resorting to using a STL library more similar to GCC is probably...

...any ideas. :) The patch is applied, thanks! http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041011/019290.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041011/019291.html > The other areas which have to be resolved is the struct/class debacle > and also the hash_map usage (I am using the Visual Studio STL library) > -- my fix for the hash_map thing is too ugly to go in, so I won't even > bother to submit a patch. Unfortunately I have to link LLVM with our own > app which is using the MS STL, so resorting to using a STL library more > similar to...

...account the possibility that the LLVM source code could be compiled with Microsoft compiler on windows? Most of the problems are pretty trivial... for example: - A lot of .cpp lacked the inclusion of the <algorithm> header (I'm using the STLport-4.6.2, the Microsoft implementation of hash_map and co. is too different) - sometimes the std:: prefix is not used for 'sort' or 'find' - C99 style array wich are not supported by the Ms compiler... etc etc There's the interest for *umm* fixing that little problems? Best regards --- Paolo Invernizzi

...our pointer to where this is setup I was able to start using stdext and fix the problem. Patch attached. On Tue, 16 Nov 2004 10:25:50 +0100 Morten Ofstad <morten at hue.no> wrote: > >>I've also determined why VC++ complains about deprecated destructors > >>when using hash_map. Because it's not ANSI (yet), Microsoft decided to > >>move it from the std namespace to the stdext namespace. Use of > >>std::hash_map is therefore deprecated. Similar shenanigans have been > >>committed by gcc from one version to another. I see where this is &gt...

...yet been applied, and most of it was really uncontroversial stuff like adding some #includes and some typecasts, fixing alloca for visual C etc. I guess I just wrote too many mails so it was lost in the process, so here is a diff which includes all changes I have made, except those related to hash_map differences since my solution here is just too ugly. I fixed the INT64_MIN as pointed out by Misha Brukman and I made yet another fix for the variable length array in LiveVariables.cpp, this time using alloca. I hope these patches are acceptable, please tell me which ones have to be modified (i...

...y to consider patches, insofar as they increase LLVM's C++ standards compliance. > Most of the problems are pretty trivial... for example: > > - A lot of .cpp lacked the inclusion of the <algorithm> header (I'm > using the STLport-4.6.2, the Microsoft implementation of hash_map and > co. is too different) > - sometimes the std:: prefix is not used for 'sort' or 'find' > - C99 style array wich are not supported by the Ms compiler... > etc etc > > There's the interest for *umm* fixing that little problems? These do look interesting,...

...ssertion failure. This is the error message I get. Processing internal callee function rt_error opt: /localhome/ssahoo2/llvm/src/lib/Analysis/DataStructure/DataStructure.cpp:2248: static void llvm::DSGraph::computeNodeMapping(const llvm::DSNodeHandle&, const llvm::DSNodeHandle&, __gnu_cxx::hash_map<const llvm::DSNode*, llvm::DSNodeHandle, __gnu_cxx::hash<const llvm::DSNode*>, std::equal_to<const llvm::DSNode*>, std::allocator<llvm::DSNodeHandle> >&, bool): Assertion `Entry.getNode() == N2 && "Inconsistent mapping detected!"' failed. ../../../....

...-freebsd5.2.1 checking target system type... i386-unknown-freebsd5.2.1 test: Unknown: bad number And finally: config.status: creating Makefile.config config.status: creating include/Support/DataTypes.h config.status: creating include/Support/ThreadSupport.h config.status: creating include/Support/hash_map config.status: creating include/Support/hash_set config.status: creating include/Support/iterator config.status: creating include/Config/config.h config.status: linking ../lib/System/Unknown to lib/System/platform config.status: error: ../lib/System/Unknown: file not found

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 copied TableGen results...

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 /ISTLport-4.6.2\stlport /Illvm\include /Iinclude /Ibuild_vc71\inclu de /Illvm\include /c llvm\lib\System\Signals.cpp /Fobuild_vc71\lib\System\...