similar to: Running grep with LLI

On Sun, Sep 18, 2016 at 12:32 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Sep 17, 2016, at 3:19 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> So, when I embark on the next ThinLTO try build, probably this Sunday, >> should I append -Wl,-plugin-opt,jobs=NUM_PHYS_CORES to LDFLAGS >> and run ninja without -j or

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Hi, I'm stumped by how to handle fpowi. Here is the context: my architecture has i64, f32, and f64 registers. No i32. For calls & returns, we promote i32 to i64. There is no support in the architecture to perform fpowi - it has to go through the runtime. I'm using gfortran + dragonegg + llvm3.4 to generate .ll files via plugin. The fortran expression REAL = REAL ** INTEGER*4

Hi, I'm using KLEE which supports only LLVM-2.9. In order to compile some c++ file which requires gcc 4.5, I built Dragonegg 2.9 with LLVM-2.9 and gcc 4.5.1 on a Linux x86_64 machine. It was sucessfully built. When I try to compile a c++ file using this plugin as below gcc test.cpp -fplugin=path/dragonegg.so I got this error: cc1plus: error: Cannot load plugin path/dragonegg.so

Hi, getMetadata(“dbg”) returns NULL for such a small program as follows: int main(){ char a[10], b[2]; if(a[0] != 0 && a[1] != 0){ strcpy(a, b); } return 0; } The compiling command is: llvm-gcc --emit-llvm -g -c ./src.c I also tried the solutions I found through Google: http://stackoverflow.com/questions/14943447/llvm-line-number-of-an-instruction

Hi Philip, Thank you very much for your comments. I think I’ve discovered a root cause. The problem was in linking bit code archive files with the module. At some point, std::set<Module*> is used and iterated over. I believe this was the reason why e.g. It worked consistently with ASLR turned off and produced non-deterministic output otherwise. I changed that bit to use vector instead and