search for: namestring

On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote: > The simple-encoder helpers initialize an encoder with an empty > implementation. This covers the requirements of most of the existing > DRM drivers. A call to drm_simple_encoder_create() allocates and > initializes an encoder instance, a call to drm_simple_encoder_init() > initializes a pre-allocated instance. >

On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote: > The simple-encoder helpers initialize an encoder with an empty > implementation. This covers the requirements of most of the existing > DRM drivers. A call to drm_simple_encoder_create() allocates and > initializes an encoder instance, a call to drm_simple_encoder_init() > initializes a pre-allocated instance. >

The simple-encoder helpers initialize an encoder with an empty implementation. This covers the requirements of most of the existing DRM drivers. A call to drm_simple_encoder_create() allocates and initializes an encoder instance, a call to drm_simple_encoder_init() initializes a pre-allocated instance. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

Den 07.02.2020 09.41, skrev Thomas Zimmermann: > The simple-encoder helpers initialize an encoder with an empty > implementation. This covers the requirements of most of the existing > DRM drivers. A call to drm_simple_encoder_create() allocates and > initializes an encoder instance, a call to drm_simple_encoder_init() > initializes a pre-allocated instance. > >

Hi Am 07.02.20 um 14:37 schrieb Daniel Vetter: > On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote: >> The simple-encoder helpers initialize an encoder with an empty >> implementation. This covers the requirements of most of the existing >> DRM drivers. A call to drm_simple_encoder_create() allocates and >> initializes an encoder instance, a call to

Many DRM drivers implement an encoder with an empty implementation. This patchset adds drm_simple_encoder_init() and drm_simple_encoder_create(), which can be used by drivers instead. Except for the destroy callback, the simple encoder's implementation is empty. The patchset also converts 4 encoder instances to use the simple-encoder helpers. But there are at least 11 other drivers which can

I've just fixed a bug (#528 in bugzilla) to do with wins hook functionality. The wins hook parameter is broken in Samba 3.0.0 but will be fixed in 3.0.1. The attached patch against the release samba-3.0.0.tar.gz file can be used to fix it. Tim. -------------- next part -------------- Index: nmbd_winsserver.c =================================================================== RCS file:

...gt; +# ACPI_EXTRACT_NAME_DWORD_CONST - extract a Dword Const object > from Name() > +# ACPI_EXTRACT_NAME_WORD_CONST - extract a Word Const object from > Name() > +# ACPI_EXTRACT_NAME_BYTE_CONST - extract a Byte Const object from > Name() > +# ACPI_EXTRACT_METHOD_STRING - extract a NameString from Method() > +# ACPI_EXTRACT_NAME_STRING - extract a NameString from Name() > +# ACPI_EXTRACT_PROCESSOR_START - start of Processor() block > +# ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from > Processor() > +# ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processo...

The GEP constructor does not assert that the source and destination types match. Of course, this is incorrect and causes random failures somewhere down the line. Could I add general sanity checks to the GEP constructor? In general, is an Instruction allowed to be in an inconsistent state? If so, is there some well known method to "verify" whether an instruction is consistent or not?

Hello; I am working on porting a tool written for LLVM3.5 to LLVM10. There used to be a call instruction with the signature static CallInst * Create (Value *F, Value *Actual, const Twine &NameStr="", Instruction *InsertBefore=0) Can anyone please explain what it supposed to do? What was F and Actual? Thank you so much. -- Dr. Arnamoy Bhattacharyya R&D Compiler Engineer

Hi, supposing I have a function “foo” like the following: int foo(int a, int b) { ... ... } I want to insert int the LLVM IR a call instructions to a function “bar” that requires the same parameters of foo. So my function foo will become: int foo(int a, int b) { bar(a,b); … ... } I am using the following code: bool ThreadSanitizer::runOnFunction(Function &F) {

Hi Shuying, You will find in the documentation that amongst the overloaded CallInst::Create()'s there is one that takes no function arguments: static CallInst* llvm::CallInst::Create ( Value * F, const Twine & NameStr, BasicBlock * InsertAtEnd); Regards On 23/11/2010, at 11:20 AM, Shuying Liang wrote: > Hi, I want to insert a function with a void type parameter, > for example:

I'm using LLVM 3.3 Release. From the Class Reference Page. CallInst has a member function : static CallInst * Create (Value *Func, ArrayRef< Value * > Args, const Twine &NameStr="", Instruction *InsertBefore=0) This is what I want to use! the default name is "" and I also use that . Thanks! ----- Kind Regards! -JinHuang -- View this message in context:

Hi, I want to insert a function with a void type parameter, for example: int foo(void); OI declared fcall2 = M.getOrInsertFunction("foo", IntegerType::get(M.getContext(), 32), Type::getVoidTy(M.getContext())); then the question is how to get the void type value to make the CallInst inserted sucessfully? (what should be ********) CallInst::Create(fcall2, ******,

Hi Ralph, On Fri, 2007-07-20 at 10:38 +0100, Ralph Corderoy wrote: > Hi Chris, > I could be missing something, but shouldn't the use of dlsym() be > > char *err; > void *p; > > if ((err = dlerror())) { > error("earlier undetected dlerror: %s\n", err); > } > p = dlsym(handle, sym); > if ((err = dlerror())) { >

Hi, sivart Thanks for pointing it out. I used it, and it works. Thank you again. BTW, for any later reference, the function prototype declaration with no arguments is not what I wrote: fcall2 = M.getOrInsertFunction("foo", IntegerType::get(M.getContext(), 32), Type::getVoidTy(M.getContext())); INSTEAD, I changed to : fcall2 = M.getOrInsertFunction("foo",

Hi all, How can I create an llvm::GetElementPtrInst in which the pointer and the index are in registers previously loaded with llvm::LoadInst ? I mean, the generated instruction will be like this: %1 = getelementptr i8* %myreg1, i32 %myreg2 here, %myreg1 and %myreg2 are previously created by load instructions (llvm::LoadInst). Please, let me know if there is an example of something similar.

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,

Hi, This is probably more of a standard C++ question instead of an actual LLVM question, but here it goes anyway. I'm trying to invoke the following constructor: CallInst::CallInst(Value *Func, InputIterator ArgBegin, InputIterator ArgEnd, const Twine &NameStr, BasicBlock *InsertAtEnd); My code is: using namespace llvm; void replaceByClone(Function *f, CallInst *I){ Function *clone =

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to