similar to: [LLVMdev] Target independency using "opaque"? How to do it else?

Hi Johannes, > I'm writing a backend for our scriptlanguage compiler and I'm currently > writing an IR module for the runtime library that contains some support > routines called by generated code. > > The IR module contains calls to "malloc", which depend on the size of > "size_t". Since I don't know the target when writing the IR module for the

Thanks. I'm able to getting the asterisk calling back to my cellphone. But when I get to the authentication I get this message when I start to dial in my password: NOTICE[5178]: rtp.c:509 ast_rtp_read: Unknown RTP codec 96 received Is this a DTMF failure of some sort? Thanks again. -----Opprinnelig melding----- Fra: asterisk-users-bounces@lists.digium.com

On Nov 26, 2007, at 00:47, Jon Harrop wrote: > 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: > > [...] > > I was kind of hoping that function pointers would just magically > work, so this: > > do (if 1 <= 2 then fib else fib) 40 > > would run, but

On Monday 26 November 2007 16:21, Gordon Henriksen wrote: > Try 'Llvm_analysis.assert_valid_module m;' before you write bitcode to > figure out where things went awry. ('dump_module m;' may also help.) > GIGO applies (but garbage-in/segfault-out is more likely). Ok, thanks for the tip. > Unfortunately, even if the bindings were more strongly typed, it would > still

Hello everyone: As it is known, when you limit uplink bandwidth it usually gets downlink bandwidth to a lower value. I just want to know what is the optimal configuration for eth1 and imq0 according to some variables of tc(HTB), txqueuelen, mtu, etc. to make these packet flows less independent on an ethernet based network. Thank you in advance. -Diego

Bugs item #15225, was opened at 2007-10-31 01:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=15225&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Wx::Region.contains returns an opaque SWIG pointer type Initial Comment: On Windows

Greetings everyone! I've just written two small patches. The first one allow opacifying windows when resizing ; it adds two options to resize plugin's gconf data : opacify (int, opacify percent) & opacify_non_opaque (bool, sets if non opaque windows should be opacified when resizing) The second one just add the option opacify_non_opaque to move plugin. Both patches were

I'm looking at and running: test/Regression/Assembler/2005-05-05-OpaqueUndefValues.ll which says: ; RUN: llvm-as < %s | llvm-dis | llvm-as %t = type opaque %x = global %t undef Why is this valid? Shouldn't the assembler reject it (it doesn't)? How can a global variable be defined as opaque? What's it size? Does this just indicate that %x is some "unknown

{ i32, i32, opaque } When I try running through JIT the code, incrementing the field in such structure, I am getting an assert: Assertion failed: (Ty->isSized() && "`!"), function getAlignment, file /tmp/llvm-build/2.7/llvm/lib/Target/TargetData.cpp, line 498. I understand that C/C++ can't possibly produce such structure due to their language limitations. But llvm is

Dear LLVM members. Hi. I have a question. I woule like to know whether or not a global variable with abstract or opaque type can has initializer (constructor). For example, general assembly code: %struct.test = type { [10 x i8] } @ovm = global %struct.test { [10 x i8] c"ovmtest\00\00\00" } question: %struct.test = type { [10 x i8], opaque } @ovm = global %struct.test { [10 x

There is an issue with representing opaque types in LLVM IR modules: if two modules are using the same opaque type (which is only going to be specialised at some later stage), it is only identified by its name. But the current module linker "resolves" this as if there is a name clash, and one of that opaque types is renamed. It contradicts an intuitively expected identifier behaviour

On Mon, Jul 25, 2011 at 8:52 AM, Anton Lokhmotov <Anton.Lokhmotov at arm.com>wrote: > There is an issue with representing opaque types in LLVM IR modules: if two > modules are using the same opaque type (which is only going to be > specialised at some later stage), it is only identified by its name. But > the current module linker "resolves" this as if there is a name

On Jul 27, 2011, at 12:41 AM, Talin wrote: > What do you mean "the linker fails"? Type mismatches should not cause the linker to fail. In any case, this example should link, please provide a minimal example of two .ll files that repros what you're seeing with llvm-link. Thanks, > > It's llvm-ld that asserts here: > > Assertion failed: (N < NumContainedTys

Is it legal to substitute non struct type instead of opaque type? For example: ; 1.ll declare void @F(i32*) ; 2.ll %T1 = type opaque declare void @F(%T1*) Is it normal to replace T1 with i32 here? If yes. Will the next types are isomorphic?: %T1 = type opaque { i32, %T1* } { i32, i32* } -Stepan.

On Dec 20, 2011, at 12:11 PM, Stepan Dyatkovskiy wrote: > Is it legal to substitute non struct type instead of opaque type? > > For example: > ; 1.ll > declare void @F(i32*) > > ; 2.ll > %T1 = type opaque > declare void @F(%T1*) > > Is it normal to replace T1 with i32 here? Yes, the linker will do this, because it is forced to break type safety to link up the

OK. So if we have two modules with the same function name. This functions may not be isomorphic. For example, we can link this files, but the function types are not isomorphic: ; 1.ll %T1 = type opaque declare i32 @foo(%T1*) ; 2.ll define i32 @foo(i32* %v) {...something...} But at the same time we should not map next two functions (PR11627): ; 3.ll declare i32 @foo(i16* %v) ; 4.ll define

I'm building a StructType without a body using StructType *StructType::create(LLVMContext &Context, StringRef Name); and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after I add the body, isOpaque() == false, but isSized() is still false. If I create a StructType using StructType * StructType ::create(LLVMContext

Hi Rick, On 22/01/13 09:04, Rick Mann wrote: > I'm building a StructType without a body using > > StructType *StructType::create(LLVMContext &Context, StringRef Name); > > and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after I add the body, isOpaque() == false, but isSized() is still false. this is the standard

Hello, I'm trying to translate part of Java code in LLVM code. I have some problems with the "opaque type", I think because I did not understand how to use. So, the java code is: int[] ai; .... ai = new int[1]; I am using LLVM API in this way: //I create a pointer of Opaque type, because I don't know yet the array size! OpaqueType* ot = OpaqueType::get(); AllocaInst*

In my project I have a group of foreign types (C++ classes) that I want to use, but don't want to represent as structs within LLVM. For example, for each field in each C++ class I have a setter and getter function that I'd like to use. The setters and getters are "extern C" functions to avoid problems with C++'s name mangling. After going over the documentation it