Displaying 20 results from an estimated 2446 matches for "opaquely".
Did you mean:
opaque
2009 Sep 15
2
[LLVMdev] Opaque types in function parameters
Hi all,
I am creating a function and trying to call it using the LLVM API. It
seems that whenever the function type includes an opaque-typed
parameter, the CallInst::Create call causes an assert:
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
== Params[i]->getType()) && "Calling a function with a bad
signature!"), function init, file
2009 Sep 15
0
[LLVMdev] Opaque types in function parameters
2009/9/15 Carlos Sánchez de La Lama <carlos.delalama at urjc.es>:
> Hi all,
>
> I am creating a function and trying to call it using the LLVM API. It
> seems that whenever the function type includes an opaque-typed
> parameter, the CallInst::Create call causes an assert:
>
> Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i)
> ==
2012 Oct 08
21
[PATCH 00/14] Remove old_portio users for memory region PIO mapping
When running on PowerPC, we don''t have native PIO support. There are a few hacks
around to enable PIO access on PowerPC nevertheless.
The most typical one is the isa-mmio device. It takes MMIO requests and converts
them to PIO requests on the (QEMU internal) PIO bus.
This however is not how real hardware works and it limits us in the ability to
spawn eventfd''s on PIO ports
2008 Nov 13
0
[LLVMdev] RefineAbstractType
On Nov 12, 2008, at 5:07 PM, David Greene wrote:
> On Wednesday 12 November 2008 18:58, Chris Lattner wrote:
>> On Nov 12, 2008, at 3:37 PM, David Greene wrote:
>>>>> Unfortunately, calling FunctionType::refineAbstractType(opaque,
>>>>> void
>>>>> (...))
>>>>> doesn't work because RefineAbstractType doesn't recurse
2008 Nov 13
3
[LLVMdev] RefineAbstractType
On Wednesday 12 November 2008 18:58, Chris Lattner wrote:
> On Nov 12, 2008, at 3:37 PM, David Greene wrote:
> >>> Unfortunately, calling FunctionType::refineAbstractType(opaque, void
> >>> (...))
> >>> doesn't work because RefineAbstractType doesn't recurse down into
> >>> the
> >>> pointee types.
> >>
> >>
2006 Jun 09
1
[LLVMdev] Why Is This Illegal?
Can anyone tell me where my blunder is in the following program?
llvm-as reports:
llvm-as: testit.ll:11: Can't store 'opaque *' into space of type 'opaque
*'!
Which doesn't seem to make sense to me. What is it that is illegal about
storing a pointer to opaque in a space that is of type pointer to
opaque? Is it just that you can't store pointers to opaque?
%path =
2008 Nov 14
3
[LLVMdev] RefineAbstractType
On Wednesday 12 November 2008 19:13, Chris Lattner wrote:
> You shouldn't be refining the pointer, you should use:
>
> t1->refineAbstractType(t2)
Ok, I tried this and I get further. But the type system seems to have trouble
when refining multiple types and those types resolve to the same thing.
I turned on DEBUG_MERGE_TYPES to illustrate:
*** First function type ***
2016 Jan 15
3
Help handling opaque AArch64 immediates
Hello LLVM,
I'm playing with a new ISD::OPAQUE instruction to make hoisting first
class and eliminate a lot of tweaky flag setting/checking around
opaque constants. It's going well for the IR and x86, but I now I
need to sort out details for all the other targets.
To start, can someone please advise on the AAarch64 equivalent of
these X86 patterns?
// Opaque values become mov immediate
2019 Jul 16
2
[PATCH libnbd] generator: Define new Closure type
** INCOMPLETE **
This is the generator change as discussed on the list already.
The Python and OCaml bindings are not yet done.
It passes all [C only] tests and valgrind.
Note that nbd_add_close_callback is inconsistent with other closure
types because it passes the user_data parameter after the function.
(This is not caused by the current patch, it was already
inconsistent). We decided that
2013 Jan 15
1
[PATCH 2/3] xen_platform: Do not use old_portio-style callbacks
From: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
hw/xen_platform.c | 21 ++++++++++-----------
1 Datei geändert, 10 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index ca66047..8866468 100644
--- a/hw/xen_platform.c
+++
2019 Jul 16
0
[libnbd PATCH 2/2] RFC: generator: Handle shared callbacks in Python
[RFC because generated OCaml code needs the same treatment, but I ran
out of time to play with that. At least 'make -C python check' passes,
although coverage is not complete yet, as there is no
python/t/5XX-pread-structured-callback.py...]
[Also RFC because I'm not sure if the use of a record type for
'callback' is the best approach or most idiomatic OCaml - but hey, it
2019 Jul 16
3
[RFC libnbd PATCH 0/2] Start fixing python nbd.pread_structured_callback
Posting now that I got something to compile (at the expense of
breaking OCaml bindings), but I'm open to ideas on how to improve it.
Eric Blake (2):
generator: Tweak print_c_arg_list to take alternate first arg
RFC: generator: Handle shared callbacks in Python
generator/generator | 556 ++++++++++++++++++++++----------------------
1 file changed, 280 insertions(+), 276 deletions(-)
--
2017 Dec 22
2
Re: [BUG] Not exiting media forced a promptly close of libvirt 3.10
Hi Daniel,
sorry. Here the requested stack trace.
Best regards
Holger
=====================================================================================
Thread 18 (Thread 0x7f0d495e0700 (LWP 10742)):
#0 0x00007f0d55e690bf in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0d5892176a in virCondWait (c=c@entry=0x5557f238db28,
2009 Jun 05
2
[PATCHv3 12/13] qemu: virtio save/load bindings
Implement bindings for virtio save/load. Use them in virtio pci.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
hw/virtio-pci.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
hw/virtio.c | 31 ++++++++++++++-----------------
hw/virtio.h | 4 ++++
3 files changed, 66 insertions(+), 18 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index
2009 Jun 05
2
[PATCHv3 12/13] qemu: virtio save/load bindings
Implement bindings for virtio save/load. Use them in virtio pci.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
hw/virtio-pci.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
hw/virtio.c | 31 ++++++++++++++-----------------
hw/virtio.h | 4 ++++
3 files changed, 66 insertions(+), 18 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index
2018 Jan 25
2
Re: libvirtd hangs
Ján Tomko wrote 2018-01-18 14:27:
> On Thu, Jan 18, 2018 at 11:30:16AM +0700, Artem Likhachev wrote:
>> # strace -p 5786
>> read(53, "\0\0\0\34", 4) = 4
>> read(53, "keep\0\0\0\1\0\0\0\2\0\0\0\2\0\0\0\0\0\0\0\0", 24) = 24
>> poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12,
>> events=POLLIN}, {fd=13, events=POLLIN},
2018 Jun 13
0
"virsh" list
Hello,
I installed libvirt from package manager(debian apt) and want to modify
feture in it, so i git clone from https://libvirt.org/git/?p=libvirt.git;a=summary
But now i have trouble to start virsh.
I have traced the email:
https://www.redhat.com/archives/libvirt-users/2017-February/msg00074.html
Here is output of command below:
strace -o libvirt.log -f -s 1000 /usr/sbin/libvirtd
2011 Apr 06
2
[LLVMdev] Target independency using "opaque"? How to do it else?
Hello all,
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
runtime library, I
2009 May 25
0
[PATCH 10/11] qemu: MSI-X support in virtio PCI
This enables actual support for MSI-X in virtio PCI.
First user will be virtio-net.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
hw/virtio-pci.c | 152 ++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 112 insertions(+), 40 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 7dfdd80..294f4c7 100644
--- a/hw/virtio-pci.c
+++
2009 Jun 02
0
[PATCHv2 10/13] qemu: MSI-X support in virtio PCI
This enables actual support for MSI-X in virtio PCI.
First user will be virtio-net.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
hw/virtio-pci.c | 152 ++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 112 insertions(+), 40 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 7dfdd80..294f4c7 100644
--- a/hw/virtio-pci.c
+++