similar to: [LLVMdev] No crt2.o file found

/Have you tried to build llvm-gcc by yourself? /Not with the recent build. In times past I failed miserably at this using cygwin. Maybe I should try again? /Normally crt*.o files are built during normal gcc build process (llvm-gcc as well). However, mingw32 runtime has its own crt*.o files, which are included with binary distribution of llvm-gcc4 (mingw32 variant). /I thought that would be

I managed to get the llvm tool chain compiled on my windows machine using mingw a couple of weeks ago. When I tried to run the simple test case provided in the documentation I ran into a problem of missing object files. I attempted to compile the simple hello.c hello world application. Unfortunately I get the following $ llvm-gcc hello.c -o hello.exe ld: crt2.o: No such file: No such file

Hello, Matthew > I managed to get the llvm tool chain compiled on my windows machine > using mingw a couple of weeks ago. Have you tried to build llvm-gcc by yourself? > $ llvm-gcc hello.c -o hello.exe > ld: crt2.o: No such file: No such file or directory Normally crt*.o files are built during normal gcc build process (llvm-gcc as well). However, mingw32 runtime has its own crt*.o

Hi all, After being able to build llvm and llvm-gcc on windows/mingw, I am running into problems with linking. It seems llvm-gcc isn't able to find crt2.o. Ronald

Hello, Matthew. > Not with the recent build. In times past I failed miserably at this using cygwin. Maybe I should try again? Well, actually I mean: whether llvm-gcc binary under consideration was built by yourself or you're using pre-built binaries from downloads section? If you're using llvm-gcc4 binary from downloads section, mingw binary is included into tarball, you might find

Hello, Matthew. > I figured as much. It would be great to get the mingw branch on > windows working, since it avoids the cygwin dll and some restrictive > licensing issues. Mingw32 branch is quite ok as the time of writing this lines :) I was able to compile Qt with llvm-gcc4 1.9 and everything was fine. So, I suppose something went wrong during unpacking tarball or something like

Hello, Matthew. > > I figured that just copying the mingw crt*.o files would not > > be a good idea. > /Why not? Mingw32 crt does not depend on LLVM. /I rashly copied all the *.o files from my mingw\lib directory to the llvm\lib directory. This does enable the hello world binary to compile and to function correctly. However the byte code file does not work correctly giving:

Hello, Matthew. > Hmm there is no llvm-gcc directory in either the patch file or what made it > on to my system. Furthermore there are no crt*.o files after my build until > I put them in the lib directory, which where they are in the patch file. > Again the clean must have removed them. Well. Actually you should have 2 trees: 1. One you're building LLVM in. There is directory

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

Hi Adam, > OK. I know the reason you cannot reproduce it, before posting > the patch I've decided to check for AVX before checking AVX2, > just not to cpuid AVX2 when we don't have AVX1 anyway. I suspect it was also incompetence on my part. Given the differences I'm seeing now I can't believe there'd be *no* difference in my tests if I'd done them properly.

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

Henning, I believe the code that is supposed to do this is in: lib/Target/X86/X86Subtarget.cpp in X86Subtarget::AutoDetectSubtargetFeatures() Is there a bug in that function? -Hal On Thu, 24 May 2012 23:56:48 +0200 (CEST) Henning Thielemann <llvm at henning-thielemann.de> wrote: > > On Thu, 24 May 2012, Pan, Wei wrote: > > > Very likely AVX is not enabled in your llc.

Chris Lattner <clattner at apple.com> writes: > On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: > >> In X86Subtarget.h there is a method `getDataLayout' which selects the >> data layout depending on the platform, ignoring whatever the user setted >> with Module::setDataLayout. >> >> What's the rationale for this? > > Data layout is a

Does this fix it? Index: lib/Target/X86/X86Subtarget.h =================================================================== --- lib/Target/X86/X86Subtarget.h (revision 48879) +++ lib/Target/X86/X86Subtarget.h (working copy) @@ -144,9 +144,12 @@ std::string getDataLayout() const { const char *p; - if (is64Bit()) - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; -

Probably better to move the discussion to a bug? Evan On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote: > Does this fix it? > > Index: lib/Target/X86/X86Subtarget.h > =================================================================== > --- lib/Target/X86/X86Subtarget.h (revision 48879) > +++ lib/Target/X86/X86Subtarget.h (working copy) > @@ -144,9 +144,12 @@ > >

> That's far more worrying to me than not being able to detect Haswell. > I can't reproduce the problem here at the moment: both debug and > release builds give identical assembly for Host.cpp. OK. I know the reason you cannot reproduce it, before posting the patch I've decided to check for AVX before checking AVX2, just not to cpuid AVX2 when we don't have AVX1 anyway.

I agree with Tim, you need to implement a GetCpuIDAndInfoEx function in Host.cpp and pass the correct value to ecx. Also you need to verify that 7 is a valid leaf because an invalid leaf is defined to return the highest supported leaf on that processor. So if a processor supports say leaf 6 and not leaf 7, then an access leaf 7 will return the data from leaf 6 causing unrelated bits to be

hi ��f�� but in the source code i find this comment. // ELF is a reasonably sane default and the only other X86 targets we // support are Darwin and Windows. Just use "not those". does this means that we can debug jit on windows? i am confused.help 2011/6/7 ��f�� <chenwj at iis.sinica.edu.tw>: > Hi, Tang > >> result is correct. But on windows, i failed. Why? I build

I'm writing a compiler using LLVM, and suddenly today I started to get this error, when emitting to a .s file. Assertion failed: (I != M+Size && I->FromReg == RegNum && "Invalid RegNum"), function getLLVMRegNum, file MCRegisterInfo.cpp, line 78. I'm emitting using x86_64-apple-darwin. Any thoughts about what could be causing this? LLVM validation does not

Chris Lattner <clattner at apple.com> writes: > On Jul 5, 2010, at 3:31 AM, Óscar Fuentes wrote: > >> Chris Lattner <clattner at apple.com> writes: >> >>> On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: >>> >>>> In X86Subtarget.h there is a method `getDataLayout' which selects the >>>> data layout depending on the