Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] building cross llvm-gcc for new target"
2008 May 01
0
[LLVMdev] building cross llvm-gcc for new target
On Apr 30, 2008, at 11:19 PM, james woodyatt wrote:
>> $TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not
>> fixed up
You need to run the compile with -save-temps and then look at the .s
file. If you like it, it is an assembler bug. If you don't like it,
it is a bug in the compiler. If you don't know if you like it, as
your assembler vendor (binutils)
2010 Jan 26
2
[LLVMdev] another minor problem with the ocaml binding
everyone--
I notice that Llvm.llvm_handle_to_type is actually defined to create a type handle from a type, rather than vice versa as its name would imply. Should I send a patch to change the name of the function to reflect its type better, or should I just lump it?
—
j h woodyatt <jhw at conjury.org>
http://jhw.vox.com/
2010 Mar 02
1
[LLVMdev] parameter attributes and function types
On Mar 1, 2010, at 09:56, james woodyatt wrote:
> On Mar 1, 2010, at 04:43, Duncan Sands wrote:
>>
>> Where exactly? I don't see it in the online version.
>
> See <http://llvm.org/docs/LangRef.html#t_function> and look at the second example:
>
> float (i16 signext, i32 *) *
>
> Pointer to a function that takes an i16 that should be sign extended
2010 Feb 19
5
[LLVMdev] glasgow haskell appears to be adopting LLVM
everyone--
File this under Advocacy.
See this thread <http://www.haskell.org/pipermail/glasgow-haskell-users/2010-February/018425.html> for more information, but the short summary is that they're deprecating their old "compile to GCC" backend in favor of David Terei's new LLVM backend. They're still planning for their C-- backend to be the primary backend for native
2008 May 13
2
[LLVMdev] memcpy and bootstrapping
everyone--
I don't know whether this is a bug or not.
I'm trying to bootstrap an embedded application and using LLVM tools
to generate the assembly code, which I then assemble and link with
traditional tools. The bootstrap loader, of course, runs in a very
limited environment, and I have to roll my own memcpy() function for
it, i.e. there is no kernel, nothing at all, this stuff
2009 Dec 27
2
[LLVMdev] ocaml bindings
everyone--
The OCaml bindings need help again.
diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml
--- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800
+++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800
@@ -42,13 +42,18 @@
| External
| Available_externally
| Link_once
+ | Link_once_odr
| Weak
+
2010 Feb 19
0
[LLVMdev] ocaml survey
On Feb 18, 2010, at 12:51, Erick Tryzelaar wrote:
>
> I'm in the process of finishing up the ocaml llvm bindings, and I had
> some last minute questions before we code freeze:
>
> 1. What version of ocaml is everyone using, and how old of an ocaml
> version do you need to support?
Still using OCaml 3.11.1, but will but upgrading to OCaml 3.11.2 around the same time as the
2010 Mar 02
0
[LLVMdev] parameter attributes and function types
On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote:
> On Mar 1, 2010, at 09:56, james woodyatt wrote:
>> On Mar 1, 2010, at 04:43, Duncan Sands wrote:
>>>
>>> Where exactly? I don't see it in the online version.
>>
>> See <http://llvm.org/docs/LangRef.html#t_function> and look at the second example:
>>
>>
2010 Mar 01
3
[LLVMdev] paramter attributes and function types
On Mar 1, 2010, at 04:43, Duncan Sands wrote:
> [I wrote:]
>>
>> Nevertheless, the LLVM Language Reference document suggests, in the examples for the Function Types section, that parameter attributes are part of function types.
>
> Where exactly? I don't see it in the online version.
See <http://llvm.org/docs/LangRef.html#t_function> and look at the second
2011 Jun 22
0
[LLVMdev] ARM thumb-2 instruction used for non-thumb2 CPUs
On Jun 22, 2011, at 7:27 PM, Jim Grosbach wrote:
>> I will try to find those pre-v3 patches.
>>
>> In meantime I wrote a patch which changes to old mnemonics for shift instructions.
>> This fixes compiling on the freebsd.
>
> If this is really the only issue you're seeing, we may be lucky and your binutils already have support for lots of the changes necessary
2010 Mar 11
2
[LLVMdev] setting parameter attributes on function returns
everyone--
Maybe I'm missing it, but I don't see how to apply parameter attributes to function return types in either the C-language or OCaml bindings. Can anybody help clue me in? Thanks.
—
j h woodyatt <jhw at conjury.org>
http://jhw.vox.com/
2010 Mar 04
4
[LLVMdev] Last chance to get anything into llvm-c and ocaml bindings
I've pretty much finished exposing all I wanted to llvm-c and the
ocaml bindings for the soon to be released 2.7. Does anyone need any
other functions exposed before the code freeze on the 7th?
2010 Feb 18
6
[LLVMdev] ocaml survey
I'm in the process of finishing up the ocaml llvm bindings, and I had
some last minute questions before we code freeze:
1. What version of ocaml is everyone using, and how old of an ocaml
version do you need to support?
2. Would it be alright if I renamed some functions? Module providers
are being removed for 2.7. I can keep the old functions around, but
I'd prefer to keep the API clean.
2008 May 13
0
[LLVMdev] memcpy and bootstrapping
james woodyatt wrote:
> everyone--
>
> I don't know whether this is a bug or not.
I assume you're using llvm-gcc? Does it still turn memcpy into
llvm.memcpy if you pass llvm-gcc -ffreestanding? If so, that's certainly
a bug. Either way, you should be using -ffreestanding!
Nick
> I'm trying to bootstrap an embedded application and using LLVM tools
> to
2009 Dec 28
0
[LLVMdev] ocaml bindings
On Dec 27, 2009, at 11:41 AM, james woodyatt wrote:
> everyone--
>
> The OCaml bindings need help again.
Please attach this as a .patch file and I'd be happy to apply it for you,
-Chris
>
> diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml
> --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800
> +++
2010 Mar 02
1
[LLVMdev] parameter attributes and function types
On Mar 1, 2010, at 20:28, Eli Friedman wrote:
> On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote:
>> I'm sorry to pester about this, but I was really hoping somebody could straighten me out about this. The Language Reference really does seem to be ambiguous about this, and I'm willing to compose a patch to fix it, but I need to know what the
2010 Feb 07
0
[LLVMdev] another minor problem with the ocaml binding
to me the name implies that it creates a handle to the type given, i guess
if you look at it in context of the ocaml conversion functions some people
may think otherwise.
On Tue, Jan 26, 2010 at 6:49 PM, james woodyatt <jhw at conjury.org> wrote:
> everyone--
>
> I notice that Llvm.llvm_handle_to_type is actually defined to create a type
> handle from a type, rather than vice
2010 Feb 28
1
[LLVMdev] C Compiler written in OCaml, Pointers Wanted
On Wednesday 24 February 2010 13:26:33 Jianzhou Zhao wrote:
> On Wed, Feb 24, 2010 at 7:10 AM, Jon Harrop <jon at ffconsultancy.com> wrote:
> > On Wednesday 24 February 2010 03:58:03 Jianzhou Zhao wrote:
> >> I think LLVM OCaml bindings do not support JIT too much.
> >
> > Can you elaborate on this?
>
> I meant the OCaml bindings let OCaml call existing
2010 Dec 21
2
[LLVMdev] the optional function return attribute and the llvm-c bindings
everyone--
Is it my imagination, or is there no way in LLVM 2.8 (or current trunk) to use the facilities defined in <llvm-c/Core.h> to get or set the optional return parameter attribute on a function value?
All the functions in the "Operations on parameters" parameters section actually seem to work only on the function arguments and not the return parameter. Is this intentional?
2008 May 06
1
[LLVMdev] ARM TargetLowering broken?
everyone--
My build of LLVM-GCC from top-of-trunk sources is failing with the
assertion in ARMISelTargetLowering at line 667, in LowerRET, where it
says "Do not know how to return this many arguments!" This happens
when the cross-compiler attempts to build _muldc3 for libgcc2.
The more I have investigated this problem, them more convinced I have
become that this isn't a