similar to: [LLVMdev] [patch] native AMD64 support

Hi, I'm just getting back to working on the cfe debug info after a brief hiatus. It appears that the appropriate place to be inserting stoppoints is starting in llvm_expand_stmt, using STMT_LINENO(t) . If that's not the best place, comments would be appreciated. Using the debug_hooks seems to be a non-starter, because they're called during rtl generation, which apparently isn't

Markus F.X.J. Oberhumer schrieb: > Stefan Strasser wrote: > >> I've encountered a few bugs including ICE and reject-valid when >> compiling a program with llvmg++ which compiles fine with standalone g++. >> >> Should I report those to your bugzilla or is it likely that these bugs >> are gcc bugs in the version of gcc you're using? >> if so, are

Hi, This is a simple question about building ARM cross-compiler. What is the building procedure using LLVM 2.4 and GCC front-end 4.2? I used these commands for LLVM, and it is okay. $ ../configure --prefix=/usr/local -target=arm $ make ENABLE_OPTIMIZED=0 $ make ENABLE_OPTIMIZED=0 install Then these commands were used for GCC front-end but this got couple of errors. $ ../configure

I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works fine. However, I can't submit that to the repository. On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and GCC 4.7. I wasn't able to build DragonEgg 3.0

2008/12/28 Keun Soo Yim <yim6 at illinois.edu> > This is a simple question about building ARM cross-compiler. > What is the building procedure using LLVM 2.4 and GCC front-end 4.2? > > I used these commands for LLVM, and it is okay. > > $ ../configure --prefix=/usr/local -target=arm > $ make ENABLE_OPTIMIZED=0 > $ make ENABLE_OPTIMIZED=0 install > > Then

> See ix86_return_in_memory. (In 4.3 this is renamed to > return_in_memory_32.) > i128==TImode. But TImode should be used for __m128 stuff only there, not for integers. I'm looking into gfortran now. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Mark Kromis wrote: > On Dec 27, 2008, at 7:41 PM, Misha Brukman wrote: >> 2008/12/27 Mark Kromis <greybird at mac.com> >> Just a curiosity question, why push for gtest vs Boost Test or a >> different test suite? >> I normally use Boost, and their test suite, so I'm more familiar with >> that. So I was wondering is one better then the other, or is it

Can anyone shed some light on the origins of the comments... /* Mach-O doesn't support omitting the frame pointer for now. */ ...in gcc/config/i386/i386.c. FSF gcc trunk has enabled the omit-frame-pointer option as the default for both i386 and x86_64 recently. * config.gcc: Handle --enable-frame-pointer. * configure.ac: Add --enable-frame-pointer. * configure: Regenerated. *