similar to: [LLVMdev] Linker problems with Visual Studio

On Thu, 14 Oct 2004, Morten Ofstad wrote: > 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

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 * is not used

> 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

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

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

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 10:20:39 +0200 > >I'm using scons to generate that files from .in files. I implemented in it >the configure check regarding iterators, hash and so on... >something like: > Hey, you've found the tool that makes it possible to generically reading Makefiles... Cool - The tool I've

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 11:18:00 +0200 >If VC6 is not doing something wrong with templates... ;-/ As far as I know is template handling a part of some C++ ISO standard. Then, MS should adhere to this... However, what you objects against is that MS didn't implement STL the way STL should be implemented. And the reason to

Uh... this may be a silly question, but why can't you include <stdio.h>? It'd be much better than <iostream>. Anyway, I think I'll try this weekend to come up with my own way of building on Win32. I prefer that building on Windows depends only on Microsoft and GNU tools, and the fewer of the latter the better. My gut instinct is to capture all the files generated by

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:

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

I have some patches of my own: * An improvement on 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),

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 that for those using HashExtras. Regards, Ryan

Well, I just tried to copy the files generated by configure to Windows for building there. It's a non starter. They are totally dependent on the Unix environment and it would be simpler to start from scratch. The scons approach of generating VC project files is very interesting (but what about the solution file?). Unfortunately, a serious attempt at this would take far more time than I

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 all, Well, suggestion for workarounds for the namespace problems are welcome... this is a 7 minutes compile files on a pentium 4 3ghz 700Mb ram... The fatal error at the end MAY depend on the previous... or at least, I hope so. cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /ISTLport-4.6.2\stlport /Illvm\inc lude

Jeff, On Mon, 2004-11-15 at 21:43, Jeff Cohen wrote: > I have some patches of my own: > > * An improvement on 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. > Thanks for the

>>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

Hi, several of the patches I submitted last week have not 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

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 sort of plan because I know