similar to: [LLVMdev] Saving preprocessed source and/or assembly

Hi, In the quest for better test cases for my MP, I thought of trying the Stepanov Abstraction Penalty benchmark. But apparently llvm-g++ is not ready for such terrible things. Let me know if you want me to send the source code (it is widely available). gaeke|csil-suna37|~/cs/426/MP1/step|[1177]% /usr/dcs/projects/cs426/Software/gcc_install/bin/g++ stepanov.cpp -o stepanov In file included from

Hi, I spent a bit of time making llvm link on FreeBSD 5.1-RC1 (i686) tonight. (I didn't run any tests.) Here are the issues I ran into: 0. Need a llvm/Makefile.FreeBSD; Makefile.Linux unchanged worked OK 1. libdl doesn't exist; remove TOOLLINKOPTS=-ldl to link tools that use libdl 2. include/Support/DataTypes.h doesn't work for FreeBSD; I hacked a new version 3. alloca.h doesn't

On Fri, Apr 8, 2016 at 11:28 AM, Hans de Goede <hdegoede at redhat.com> wrote: > When dealing with non vector variables the llvm register allocator > will use TEMP[0].x then TEMP[0].y, etc. > > When loading something from a global buffer it will calculate the > address to use, and store that in say TEMP[0].x, so it ends up > generating: > > LOAD TEMP[0].y, MEMORY[0],

Stefan Weigert wrote: > hi, > > when using the execution engine (no matter, if JIT or Interpreter) i get the > following assertion as soon as i use boost::shared_ptr: > > /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: > void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const > llvm::TargetInstrDesc*): Assertion `0 &&

hi, thanks for your quick replies. -DBOOST_SP_USE_PTHREADS worked indeed. however, i didn't measure the performance but i would assume that the boost developers had a good reason for using assembler in this context. will llvm ever support inline assembly? is there anybody who is working on that? thanks, stefan. On Tuesday 21 July 2009 01:54:20 pm Vladimir Prus wrote: > Stefan Weigert

Please CC me directly as i'm not on the list. I have attached a patch against latest CVS (cvs diff -u) that adds the following functionality. I can break it up if you would prefer it in pieces. Comments welcome. o add compare-perms option This creates a new inode for a file even if only the perms have changed. This way if a file outside of destdir is hardlinked to a dentry inside

Hi, On 08-04-16 18:06, Hans de Goede wrote: > Hi, > > On 08-04-16 17:45, Ilia Mirkin wrote: >> On Fri, Apr 8, 2016 at 11:28 AM, Hans de Goede <hdegoede at redhat.com> wrote: >>> When dealing with non vector variables the llvm register allocator >>> will use TEMP[0].x then TEMP[0].y, etc. >>> >>> When loading something from a global buffer

See attached build (gmake -k) log. -- gaeke at uiuc.edu -------------- next part -------------- gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib' gmake[2]: Entering

Hello hackers, I seem to be having some trouble compiling the top of the llvm CVS tree... Is someone working on something involving IPModRef.cpp and the data structure graph? I have attached a make -k log. -Brian -- gaeke at uiuc.edu -------------- next part -------------- gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Nothing to be done for

Hi, On 08-04-16 17:45, Ilia Mirkin wrote: > On Fri, Apr 8, 2016 at 11:28 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> When dealing with non vector variables the llvm register allocator >> will use TEMP[0].x then TEMP[0].y, etc. >> >> When loading something from a global buffer it will calculate the >> address to use, and store that in say TEMP[0].x,

mmh.. At the moment there are 3 distinct preprocess functions that operate on 2 different types: - info_rw_t - preprocess(); - item_t - preprocess(); - item_t - preprocess_answer(). For info_rw_t: range/enum values are preprocessed just to see if that specific value is to be used or not depending on the conditions the driver meets at runtime (e.g.: low voltage devices -> low voltage ranges).

The plugin version (and LLVM) are LLVM 3.9.0 (the release source tarball). I've attached the source files and the temporary files generated. `a.o` is the "MAIN" module. `b.o` is the "ASM" module. The error I get is: /usr/bin/ld: error: a.o.thinlto.o: multiple definition of 'foo' /usr/bin/ld: b.o.thinlto.o: previous definition here (the files depend on D runtime

Hi and thank you for your effort. You are very close to what I want to achieve, but I was already aware of the impossibility of querying direct from a command. I wanted the following (both would be covered by your changes): 1. preprocess an item_t in the direction: NUT->DEVICE in order to be able to support queries like ups.generated.yesterday

Hello, Everyone. I'm currently trying to bootstrap llvm-gcc4 on mingw32 platform. Everything (except some small fixes) seems to be fine: stage1 finished successfully. I'm linking with debug variant of LLVM, since linker bug prevents release builds. Unfortunately, stage2 failes immediately with this cryptic message: $/f/tmp/llvm/gccbuild/gcc/xgcc -B/f/tmp/llvm/gccbuild/gcc/

I have run into a problem loading a just saved R object using R-devel. I have been saving and loading this particular type of R object for a long while and never ran into this problem. I save, then immediately reload (to test save) and get "ReadItem: unnknown type 65". This error is reproducible after logout from server and restart of emacs and R. Below is my output and

I have run into a problem loading a just saved R object using R-devel. I have been saving and loading this particular type of R object for a long while and never ran into this problem. I save, then immediately reload (to test save) and get "ReadItem: unnknown type 65". This error is reproducible after logout from server and restart of emacs and R. Below is my output and

Whoops, I forgot to cc the list. Sorry. ----- Forwarded message from "Brian R. Gaeke" <gaeke at uiuc.edu> ----- Date: Thu, 13 Nov 2003 15:35:34 -0600 From: "Brian R. Gaeke" <gaeke at uiuc.edu> To: Reid Spencer <reid at x10sys.com> Subject: Re: [LLVMdev] Headers & Libraries Hi Reid, Sorry I can't go into as much detail as your question did right

With `save-temps` as plugin option, I get extra files for the MAIN module (called `a.o`): `a.o.opt.bc` and `a.thinlto.bc`. The `a.thinlto.bc` file contains nothing, only `source_filename = ...` . The `a.o.opt.bc` (this looks like the result after ThinLTO importing and optimization) contains the assembly block that it should not have: ``` module asm "\09.text" module asm

On Wed, Aug 29, 2018 at 10:14 AM, Hans Wennborg <hans at chromium.org> wrote: > On Wed, Aug 29, 2018 at 9:45 AM, Sedat Dilek via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> for filing a GCC v8.2.0 bug in Debian/buster AMD64 the Debian/GCC >> mainatiners want two things... >> >> [ FULL CMAKE LINE ] >> >> How do I

I'm not entirely sure what caused this, but the following code, which used to behave as expected, is now broken: ---- lolwut.c ---------------------------- void lolwut(void) { __asm __volatile ( "ldr r1, =1f \n" ".ltorg \n" "1: \n\t" : : : "r0", "r1" ); } ------------------------------------------- ~/clang