similar to: [LLVMdev] Remaining Visual C patches

On Mon, 25 Oct 2004, Morten Ofstad wrote: > 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. Oops, sorry about that. :( > I guess I just wrote too many mails so it was lost in the process, so > here is a diff which includes all

Chris Lattner wrote: > The two patches I didn't apply are the one that affects the interpreter > (I'll let Brian tackle it as he's the interpreter guy), and this one: > > =================================================================== > RCS file: /var/cvs/llvm/llvm/include/llvm/CodeGen/MachineBasicBlock.h,v > retrieving revision 1.39 > diff -u -r1.39

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

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:

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

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

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

> 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

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

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

Hi, I'm terribly sorry that I missed this before 3.7p1 was out. The permanently_set_uid() function fails on Cygwin since the test to revert to the saved uid unfortunately works on Cygwin though it shouldn't. The reason is that a Windows NT process always can revert to its previous privileges. There's no such concept of giving up rights in a process permanently. This is only

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

Hi all, I've read with interest the threads of August about a win32 port (without cygwin), and as a joke yesterday I tried compiling LLVM on win32 with VC7.1, targeting the HowToUseJIT example... Well, apart from obvious problems, it went pretty well. I cannot reach the end of the process, but I'm feeling it's not too far. So the point is: Are you interested in taking in account

> Are you interested in taking in account the possibility that the LLVM > source code could be compiled with Microsoft compiler on windows? If you think it's not too far off, then we'd be happy 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

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

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

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