similar to: [LLVMdev] Improving OCaml bindings

(readding llvmdev) On Sun, Nov 3, 2013 at 1:40 AM, Peter Zotov <whitequark at whitequark.org>wrote: > Sean Silva писал 03.11.2013 09:22: > >> On Sat, Nov 2, 2013 at 9:04 PM, Peter Zotov <whitequark at whitequark.org> >> wrote: >> >> Hello folks. >>> >>> I'm very interested in improving LLVM's OCaml bindings. I have

-llvm-commits, +llvmdev > On Oct 2, 2014, at 2:57 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > Author: dexonsmith > Date: Thu Oct 2 16:56:57 2014 > New Revision: 218914 > > URL: http://llvm.org/viewvc/llvm-project?rev=218914&view=rev > Log: > DI: Fold constant arguments into a single MDString > > This patch addresses the first

On 2016-01-30 07:39, Eric Christopher wrote: > On Fri, Jan 29, 2016 at 8:38 PM whitequark <whitequark at whitequark.org> > wrote: > >> On 2016-01-30 07:36, Eric Christopher wrote: >>> It's known to be failing right now because of recent changes, but >> I'm >>> curious why that bot has ocaml installed for the bindings? >> >> I would

On Fri, Jan 29, 2016 at 8:38 PM whitequark <whitequark at whitequark.org> wrote: > On 2016-01-30 07:36, Eric Christopher wrote: > > It's known to be failing right now because of recent changes, but I'm > > curious why that bot has ocaml installed for the bindings? > > I would guess because I've been asking for OCaml to be installed > for quite some time

On 2016-01-30 07:36, Eric Christopher wrote: > It's known to be failing right now because of recent changes, but I'm > curious why that bot has ocaml installed for the bindings? I would guess because I've been asking for OCaml to be installed for quite some time :) > > -eric > > On Fri, Jan 29, 2016 at 8:34 PM Dmitri Gribenko via llvm-dev > <llvm-dev at

Hello. I've managed to create a bitcode file (attached; also available at [1]) which produces a series of identical errors when verified: | Global variable initializer type does not match global variable type! | %i.NilClass* @nil When ran through llvm-dis and recompiled, through, it verifies successfully. If I disassemble it one more time, the result is identical to the first

Hi Peter, Could you take a look at this failure? http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-debian-fast/builds/35168/steps/test/logs/stdio Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

Newbie to Asterisk I've been looking around for a little while, can't seem to find some sample configs for using a Cisco 7206 as a gateway. The below link is an initial plan of an Asterisk solution that may replace our Cisco Call Manager 3.1/ IPCC / IVR setup. We currently have all of the hardware below. Just take a peak and see if there is anything that is off base. I don't know

On Mon, Dec 8, 2014 at 8:39 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote: >> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: >>> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one

From: Sylvain Gault <sylvain.gault at gmail.com> For the compression / decompression to succeed, the sections layout must be the same between the virtual memory and load memory. The section alignment was kept in sync by introducing aligment that should be greater or equal to the actual section alignment. This patch compute the load memory addresses of the sections so that the layout is the

From: Sylvain Gault <sylvain.gault at gmail.com> TL;DR: The section aligment in linker scripts messed-up the memory mapping needed for the compression / decompression to work. The bug with gcc 5 is not trivial, I'll do my best to explain it here. Basically, there are two memory mappings of the code. One in "virtual memory", and one in "load memory". The one in

Hi, This is a proposal to add an option to lld that forces .dynamic sections to be read-only. The .dynamic section is almost read-only except for the DT_DEBUG entry which requires the dynamic linker to modify a word. MIPS has long since had a solution to this using the DT_MIPS_RLD_MAP entry to give a pointer to another section which is writable. It would be nice to have this functionality on

Peter Zotov писал 09.01.2013 19:59: > Hello. > > I've managed to create a bitcode file (attached; also available at > [1]) which produces > a series of identical errors when verified: > > | Global variable initializer type does not match global variable > type! > | %i.NilClass* @nil > > When ran through llvm-dis and recompiled, through, it verifies >

Here's my translation of the Fibonacci example into OCaml: open Printf open Llvm let build_fib m = let fibf = define_function "fib" (function_type i32_type [| i32_type |]) m in let bb = builder_at_end (entry_block fibf) in let one = const_int i32_type 1 and two = const_int i32_type 2 in let argx = param fibf 0 in set_value_name "AnArg" argx; let

Hi all, It looks like I ended up reviewing most C API patches over the last few years. There's currently no code owner listed for the C API. I'd like to take it so that contributors know to tag me as a reviewer. Any objections? -- whitequark

Here is a complete 104-line native code compiler for a tiny subset of OCaml that is expressive enough to compile an external Fibonacci program: type expr = | Int of int | Var of string | BinOp of [ `Add | `Sub | `Leq ] * expr * expr | If of expr * expr * expr | Apply of expr * expr type defn = | LetRec of string * string * expr open Camlp4.PreCast;; let expr = Gram.Entry.mk

Ah, that's why Clang is obsessively pushing them into return by reference? On Thu, May 24, 2018 at 6:29 PM, whitequark <whitequark at whitequark.org> wrote: > On 2018-05-25 00:39, Alexandre Isoard via llvm-dev wrote: > >> Hello, >> >> I see here: https://llvm.org/docs/LangRef.html#ret-instruction >> >> That the return instruction must only return

Hi all, We quickly talked with whitequark on IRC about this. I think he makes a good candidate. I also wrote and reviewed a lot of code in there, so if that's needed I can be in there. In any case, I voutch for whitequark. Amaury Séchet 2018-04-12 0:54 GMT+02:00 whitequark via llvm-dev <llvm-dev at lists.llvm.org>: > Hi all, > > It looks like I ended up reviewing most C API

Your understanding is correct. It saves a small number of physical pages. It's strictly better even if it's only a little bit better. On Tue, May 16, 2017, 5:14 PM Rui Ueyama <ruiu at google.com> wrote: > Hi Jake, > > Thank you for sending this to llvm-dev! > > If I understand correctly, your motivation to add an option to make > .dynamic sections read-only is to

On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote: > In the Zig frontend, we know at compile-time the entire call graph. > This means we know stack size for all functions and therefore the > upper bound stack usage. > > [snip] > 1. Is there a way to accomplish this with existing LLVM API? You should use the @llvm.stacksave and @llvm.stackrestore intrinsic. It is only legal