similar to: jacobi.root, scre.eq, cgf.0, cgf.1 and cgf.2 R-plus functions nee ded

> Try building with "make VERBOSE=1", which will show you the > command-lines passed to the compiler/linker. Post the output here. there you go: > cafxx at ubuntu:~/Projects/llvm2/lib/Transforms/cgf$ make VERBOSE=1 > llvm[0]: Compiling CGFPass.cpp for Debug+Asserts build (PIC) > if g++ -I/home/cafxx/Projects/llvm2/include >

> Looks like your shared library is not being compiled with symbols. > Did you verify that your sources are compiled with -g? I think so, this is the makefile (based on the one in the Hello pass): > LEVEL = ../../.. > LIBRARYNAME = CGF > LOADABLE_MODULE = 1 > USEDLIBS = > > ifneq ($(REQUIRES_RTTI), 1) > ifneq ($(REQUIRES_EH), 1) > EXPORTED_SYMBOL_FILE =

On Jun 24, 2011, at 10:34 AM, Carlo Alberto Ferraris wrote: > >> Looks like your shared library is not being compiled with symbols. Did you verify that your sources are compiled with -g? > I think so, this is the makefile (based on the one in the Hello pass): >> LEVEL = ../../.. >> LIBRARYNAME = CGF >> LOADABLE_MODULE = 1 >> USEDLIBS = >> >>

I'm working on a pass (both LLVM and the pass have been compiled in debug+asserts mode) but when the pass crashes in the stack trace printed by opt the names of the functions inside my pass don't appear (see frames 14-16). How can I have them displayed? > cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ clear && ./opt > -load=CGF.so -cgf -debug test.S > [...] >

> Are you loading the shared library directly from the build directory, > or are you installing it first? I'm invoking it directly, I guess:./opt -load=CGF.so -cgf -debug test.S should I install it? (I have no idea about how to do it, though...) > If you run "file CGF.so" on the file you actually load, does it say it > is stripped or non-stripped? cafxx at

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to

On Jun 24, 2011, at 10:49 AM, Carlo Alberto Ferraris wrote: > >> Try building with "make VERBOSE=1", which will show you the command-lines passed to the compiler/linker. Post the output here. > there you go: >> cafxx at ubuntu:~/Projects/llvm2/lib/Transforms/cgf$ make VERBOSE=1 >> llvm[0]: Compiling CGFPass.cpp for Debug+Asserts build (PIC) >> if g++

> That's a weird one. Does addr2line work? > $ addr2line -e CGF.so <address> cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ objdump -t ../lib/CGF.so | grep flatten 0000000000005622 l F .text 0000000000000aa6 _ZN12_GLOBAL__N_111CGFFunction7flattenEv 00000000000041d6 l F .text 000000000000049c _ZN12_GLOBAL__N_111CGFCallSite7flattenEv

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,

Hi, That patch was from an ongoing effort to consolidate OpenMP generation in clang. If memory serves the implementation there is still a little incomplete. It's supposed to use types from OMPConstants rather than ones it defined itself and the methods used to create the functions shouldn't need to be static. However attempting this caused a lot of errors so there might be an underlying

On Jun 24, 2011, at 11:03 AM, Carlo Alberto Ferraris wrote: > >> Are you loading the shared library directly from the build directory, or are you installing it first? > I'm invoking it directly, I guess: ./opt -load=CGF.so -cgf -debug test.S > should I install it? (I have no idea about how to do it, though...) > >> If you run "file CGF.so" on the file

On Jun 24, 2011, at 10:14 AM, Carlo Alberto Ferraris wrote: > I'm working on a pass (both LLVM and the pass have been compiled in debug+asserts mode) but when the pass crashes in the stack trace printed by opt the names of the functions inside my pass don't appear (see frames 14-16). How can I have them displayed? >> cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ clear

Thanks, Joseph and Johannes. I have not merged in anything, I am using the code from the repository as is. What is this -debug-only option, and to whom would I pass it? I am running our own JIT application, which uses clang to compile modules on the fly via clang::CompilerInstance::ExecuteAction(). Working on the assumption that there is a mismatch in the declared type of an OpenMP runtime

Yep, it happens three times, then crashes afterwards, since I removed the assert... arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @0 = private unnamed_addr global %struct.ident_t.21 { i32 0, i32 514, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @.str, i32 0, i32 0) }, align 8 arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @1 = private

Yeah, I remember encountering that error before when getting it to pass the libomp test suite. If you have a struct named "ident_t" somewhere the compiler will rename it because of the conflict with the runtime declaration. This should be solved by casting the usage to the function type found in the definition (i.e. bitcasting a struct.ident_t.21 to struct.ident_t) which solved the

Hi, All: I have a testcase which produced incorrect result, it's caused by the combination of nsw flag and ExtLdPromotion, I am leaning to say Clang set nsw flag incorrectly, but please let me know if I was wrong. Here is the reduced testcase: long long foo(int *a) { long long c; c = *a * 1405; return c; } Clang emitted the following IR (It is done by EmitMUL() in

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

On Jun 24, 2011, at 12:36 PM, Carlo Alberto Ferraris wrote: > >> That's a weird one. Does addr2line work? >> $ addr2line -e CGF.so <address> > cafxx at ubuntu:~/Projects/llvm2/Debug+Asserts/bin$ objdump -t ../lib/CGF.so | grep flatten > 0000000000005622 l F .text 0000000000000aa6 _ZN12_GLOBAL__N_111CGFFunction7flattenEv > 00000000000041d6 l

I want to write a simple backend-specific instrinsic that will just call an instruction. How should I do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180924/7faeeb3d/attachment.html>

So, when performing expression evaluation, lldb trips over an assert in clang/lib/AST/RecordLayoutBuilder because ExternalFieldOffsets doesn't contain a FieldDecl that updateExternalFieldOffset expected. I found that the assert occurs when both static and non-static member variables are present. For instance, with the following, the lldb command 'expr my_test.length()' does not