search for: num_ops

Displaying 4 results from an estimated 4 matches for "num_ops".

Did you mean: num_aps
2009 Nov 10
12
[RFC] big fat transaction ioctl
...l_usertrans *ut, + u64 *ops_completed) +{ + int i; + int *fds; + int err; + struct file *file; + struct btrfs_ioctl_usertrans_op *ops = (void *)ut->ops_ptr; + int fd1, fd2; + + fds = kcalloc(sizeof(int), ut->num_fds, GFP_KERNEL); + if (!fds) + return -ENOMEM; + + for (i = 0; i < ut->num_ops; i++) { + struct btrfs_ioctl_usertrans_op op; + int ret; + + err = -EFAULT; + if (copy_from_user(&op, &ops[i], sizeof(op))) + goto out; + + /* lookup fd args? */ + err = -EINVAL; + switch (op.op) { + case BTRFS_IOC_UT_OP_CLONERANGE: + if (op.args[1] < 0 || op.args[1] >= ut...
2016 Mar 23
1
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...with the ubiquitous practice of having 0- or 1-length array at the end of a struct and then allocating additional elements for it using malloc, or the so-called "struct hack": http://c-faq.com/struct/structhack.html For example: typedef struct { enum inst_type type; unsigned num_ops; struct operand ops[1]; } inst; // allocate an instruction with specified number of operands int *allocate_inst(unsigned num_operands) { char *mem = malloc(sizeof(inst) + sizeof(struct operand) * (num_operands-1)); return (inst *) mem; } Or maybe the reasoning is that computin...
2016 Mar 22
0
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
Reply from Michael: &x points to the start of object x, and &x - something (something != 0) points outside object x. 'c' was a complete object, so &c-8 points outside any object, hence the formation of that pointer is already invalid (as is its dereference). https://gcc.gnu.org/ml/gcc/2016-03/msg00185.html >>On Fri, Mar 18, 2016 at 8:46 AM, Daniel Berlin <dberlin
2016 Mar 19
2
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
Agree, and I did : ) Please refer to this mailing list: https://gcc.gnu.org/ml/gcc/2016-03/msg00179.html On Sat, Mar 19, 2016 at 1:25 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > I suspect you should just go ask #1 on the gcc mailing list and see what > the answer is. > We are basically trying to figure out their reasoning, but we should > instead just go ask what it is