search for: opnames

...quot;go"> package main import ( "flag" "fmt" "libguestfs.org/guestfs" "log" "os" "path/filepath" "strings" ) type Op int const ( OpUndef Op = iota OpList OpCat OpWrite ) var OpNames = map[Op]string{ OpList: "ls", OpCat: "cat", OpWrite: "write", } const usage = `%s [options] [op] [diskimage] op = [%s] options: ` func main() { var devname string var bs int var offset int64 log.SetFlags(log.LstdFlags | log.Lshortfi...

...; "libguestfs.org/guestfs" > "log" > "os" > "path/filepath" > "strings" > ) > > type Op int > > const ( > OpUndef Op = iota > OpList > OpCat > OpWrite > ) > > var OpNames = map[Op]string{ > OpList: "ls", > OpCat: "cat", > OpWrite: "write", > } > > const usage = `%s [options] [op] [diskimage] > > op = [%s] > > options: > ` > > func main() { > var devname string > var...

On Mon, Aug 20, 2012 at 04:30:13PM -0700, Jakob Stoklund Olesen wrote: > All, > > The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. > > It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

Tom, On Aug 21, 2012, at 11:21 AM, Tom Stellard <thomas.stellard at amd.com> wrote: > I've been working on replacing the MachineOperand flags in the R600 > backend with immediate operands, but I can't figure out how to modify > the instruction patterns to make this work. For example, I have the class: > > class R600_1OP <bits<32> inst, string opName,

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Use para_fill instead of directly setting the APIC ops to the result of the vmi_get_function call - this allows one to implement a VMI ROM without implementing APIC functions, just using the native APIC functions. While doing this, I realized that there is a lot more cleanup that should have been done. Basically, we should never assume that the ROM implements a specific set of functions, and

Hello All, now that the BUG 14343: (s3: vfs_full_audit: Add missing fcntl entry in vfs_op_names[] array.) was fixed I wanted to try 4.12 again. This is the relevant config which has been running for years: vfs objects = acl_xattr full_audit shadow_copy2 full_audit:failure = none full_audit:success = pwrite write rename unlink full_audit:prefix = IP=%I|USER=%u|MACHINE=%m|VOLUME=%S

Good morning list, is there a failure in that manpage? (I'm running Samba version 4.17.6-Debian) The example shows: [records] path = /data/records vfs objects = full_audit full_audit:prefix = %u|%I full_audit:success = open opendir full_audit:failure = all !open full_audit:facility = LOCAL7 full_audit:priority = ALERT But: - opendir is not shown within complete set of Samba VFS operations.

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Owen Anderson > Sent: Tuesday, August 21, 2012 11:37 AM > To: Stellard, Thomas > Cc: llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] No more TargetFlags on MO_Register > MachineOperands > > Tom, > > On Aug 21, 2012, at 11:21 AM, Tom

Hi all, I noticed that the x86 backend tends to emit unnecessary vector insert instructions immediately after sse scalar fp instructions like addss/mulss. For example: ///////////////////////////////// __m128 foo(__m128 A, __m128 B) { _mm_add_ss(A, B); } ///////////////////////////////// produces the sequence: addss %xmm0, %xmm1 movss %xmm1, %xmm0 which could be easily optimized into

There seems to be a bunch of code for making certain that gcc still works even if --enable-gcc isn't used, so I'm assuming that it's at least supposed to be a supported configuration, and hence this issue that I found should probably be looked at: If you compile llvm-gcc-4.2 _without_ --enable-gcc, and then try to compile the following program, you get a rather nasty RTL error.

I recently updated my Rannotate application. The interface has been completely redone and there are lots of new features. The basic idea is to create searchable and user annotatable documentation for the Ruby on Rails API (think php.net). Check it out at - http://rails.outertrack.com * What is Rannotate? Rannotate is a Rails application and RDoc YAML generator that work together to provide

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,