search for: kreinin

Hi! Apparently there are no precompiled binaries for llvm-gcc 4.0 for Linux. I've tried downloading the sources and building according to http://llvm.org/docs/CFEBuildInstrs.html (except I'm not an elite gcc hacker). I tried following the guidelines and got what looks like a gcc for x86 with no traces of LLVM. I tried passing --enable-llvm with various llvm root pathnames and got ICEs.

Hmm, today I just tried compiling the llvm-gcc 4.0 frontend again on linux (Fedora Core 3 I believe) and I seem to be suddenly having the problem that Yossi Kreinin mentioned. The frontend seems to be using normal gcc to compile as I no longer get a bytecode file after compilation. When I pass the --version argument it claims to be the LLVM 4.0.1 frontend. Any ideas what might cause this? It was working just fine before, I don't know what I did differently...

On 6/3/06, Reid Spencer <reid at x10sys.com> wrote: > I don't think anyone has successfully built llvm-gcc4 on Linux yet. I've > tried and failed. I have :-) There was some patches, but I believe that they were all merged in the latest snapshot. Rafael

...t: http://llvm.org/2006-06-01-llvm-gcc4-linux-x86-binary.tar.gz Reid. On Tue, 2006-06-06 at 19:17 -0700, John Trimble wrote: > Hmm, today I just tried compiling the llvm-gcc 4.0 frontend again on > linux (Fedora Core 3 I believe) and I seem to be suddenly having the > problem that Yossi Kreinin mentioned. The frontend seems to be using > normal gcc to compile as I no longer get a bytecode file after > compilation. When I pass the --version argument it claims to be the > LLVM 4.0.1 frontend. Any ideas what might cause this? It was working > just fine before, I don't know wh...

Chris asked me to write up "LLVM Developer's Guide to Dwarf Support" for LLVM maintainers. We are still in early stages, but we thought we'd get it out there for the "need to bleeders." At some point this information will be formalized and added to the LLVM documentation. The enclosed document gives specific instructions for adding source line number support

Hi! The LLVM Bytecode File Format specifies an optional SectionID attribute for globals. I didn't find a matching attribute in the LLVM source code. Code such as: int a __attribute__ ((section ("A_SECTION"))); compiles with llvm-gcc, but apparently the section information is stripped (the object file doesn't contain "A_SECTION"). Is the SectionID feature

I don't think anyone has successfully built llvm-gcc4 on Linux yet. I've tried and failed. The instructions in CFEBuildInstrs.html are for llvm-gcc3 and probably won't work as-is. Reid. On Sat, 2006-06-03 at 19:39 +0300, Yossi Kreinin wrote: > Hi! > > Apparently there are no precompiled binaries for llvm-gcc 4.0 for Linux. > > I've tried downloading the sources and building according to http://llvm.org/docs/CFEBuildInstrs.html (except I'm not an elite gcc hacker). I tried following the guidelines and got...

Hi! Apparently llvm-gcc ignores #line directives in source files when generating debug information. When I compile this: //test int f(int a) { #line 1 "someplace" return a*a; } //end with `llvm -g -S lines.c`, `someplace' is not mentioned in lines.s. It also looks like functions #included from header files get attributed to the #including file (albeit at the right line number).

Hi! A (small) tar archive with files exposing an apparent LLVM optimizer bug is attached; I didn't find a way to attach files in the bugzilla interface. What's the best way to report bugs taking several files to reproduce? -- Yossi -------------- next part -------------- A non-text attachment was scrubbed... Name: bugreport.tgz Type: application/x-gtar Size: 2242 bytes Desc: not

Hi! I'm working on an LLVM back-end for a processor with a stack machine architecture. After experimenting with code generation directly from the LLVM representation, I'm studying the target-independant code generator. As far as I understand, there currently exists a target-independant infrastructure for legalization, instruction selection, scheduling and register allocation. It is clear