similar to: [LLVMdev] qsort callbacks portability issues

Hi Jim, Thanks for reviewing the patch. I couldn't get rid of STLExtras.h, but other than that, I followed all the suggestions in your email. Please let me know if you notice anything else that needs fixing. On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Akira, > > This is looking good. Some specific comments on the details below. > >

Hi Akira, Just two very minor things that I missed the first time around. 1. The 'fixup" member of ELFRelocation entry should be "Fixup" instead. 2. Since we're always passing in a non-NULL fixup, that should probably be a reference, not a pointer. Good for commit with those tweaks. Thanks! -Jim On Mar 23, 2012, at 1:07 PM, Akira Hatanaka wrote: > Hi Jim, >

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

Hi Matt, Awesome! This is excellent progress, and it is great to see someone working on this. High level comments: (1) The order of patches is odd, to me. It would be great to start by adding the AsmParser support, then the MCStreamer support, so that we can have test cases in the 'llvm-mc cat' mode, where it just parses and prints out again. On 0001: - What is hasRelocationAddend? It

Hi guys, attached are a couple of work in progress patches for ELF support in the MC module. I'm sending this email to gather some general feedback on the code. Applying these patches doesn't get you a fully working llvm-mc that understands ELF; it's just the ground work. I've got a couple more small patches that fixup some places that assume Mach-O object format which I'll

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

The BGL (Boost Graph Library) defines tie(), which is exactly what the tie() defined in STLExtras.h. The header files of GBL use boost::tie(), and other boost libraries use boost::tie() too. How to resolve the ambiguity for compiler? -- Tzu-Chien Chiu, 3D Graphics Hardware Architect <URL:http://www.csie.nctu.edu.tw/~jwchiu>

I'm going through the Kaleidoscope tutorial, adding the codegen() functions: https://llvm.org/docs/tutorial/LangImpl03.html. I cannot find any discussion of header files to include, (other than the include of llvm/ADT/STLExtras.h in the lexer/parser code), and the compilation is failing due to several undefined symbols: LogErrorV, Value, LLVMContext, APFloat, and others. I've been hunting

Hello, When I try to create execution engine I do get "*Interpreter has not been linked in.*" error and EngineBuilder returns NULL. Here is the line I use to create execution engine: auto executionEngine = llvm::EngineBuilder(std::move(m_module)).setErrorStr(&error).create(); Here are all headers I have included: #include "llvm/ADT/STLExtras.h" #include

On Tue, 12 Oct 2004, Paolo Invernizzi wrote: > Hi all, > I cannot figure out why is named GenRegisterInfo.h.inc and not > GenRegisterInfo.inc ... > Is it for a dependency problem? I'm not sure what you're saying here. In the X86 backend, for example, we generate both X86GenRegisterInfo.h.inc and X86GenRegisterInfo.inc. The former is #included into X86RegisterInfo.h and the

> On Dec 14, 2016, at 9:37 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > One of my coworkers noticed that we(Clang/LLVM) have quite a few places where we need to iterate through 2 equally sized ranges at the same time, often related to parm/arg relationships. In a few cases we(Clang/LLVM) use a traditional for-loop with 2 iterators in it. In a few others,

Hi, When you write a program which uses the "qsort()" library function, You also have to provide an implementation of a compare funtion. Now when we convert our program into bc and then execute it, I get the number of times all basic blocks are executed. But since the comparison function is called from within the std function "qsort()", I don't get the number of times

Hi, I am trying to run an LLVM analysis on a C++ program that calls qsort(), using the LLVM interpreter (lli --force-interpreter). The code is the qsort_large.c file in the MiBench benchmark suite. If I comment the qsort() call, the execution works fine. If I uncomment the qsort() call, I run into a segmentation fault error as follows: 0 lli 0x0000000000d35c6f 1 lli

Dear All, Is there a reason why the qsort() implementation in llvm/runtime/GCCLibraries/libc/qsort.c is commented out? I've run it on Linux, and so far it seems to work fine. -- John T.

Hi, I am trying to run an LLVM analysis on a C++ program that calls qsort(), using the LLVM interpreter (lli --force-interpreter). The code is the qsort_large.c file in the MiBench benchmark suite. If I comment the qsort() call, the execution works fine. If I uncomment the qsort() call, I run into a segmentation fault error as follows: 0  lli             0x0000000000d35c6f 1  lli        

Hello, I’m trying to port a project up to 4.0 and I’m seeing the following error: In file included from /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/StringRef.h:13: /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/STLExtras.h:139:13: error: no type named 'type' in 'std::__1::result_of<std::__1::pointer_to_unary_function<llvm::DSNode *, llvm::DSNode

Solaris 5.8 has a quirky qsort that requires the ability to recognize elements as equal. here is a patch I have created to deal w/ this problem. I apologize if the patch is in the wrong format and would love to be corrected if wrong. I used the following to create the patch libvorbis-1.0> diff -u lib/psy.c lib/psy_new.c > libv.patch <p><p><p><p> --------------

Hi, just a quick question about the intent of the ApproximateLoopSize() function in LoopUnroll.cpp: If a loop contains debug stoppoint intrinsics, does it make sense to count them? My understanding is that they are removed when not running under llvm-db anyway, so we probably shouldn't make size judgements based on them. Is that right, or am I missing something? Anyway, if I'm right,