similar to: [Bug 976] invalid conversion from 'void*' to 'xt_entry_target*'

https://bugzilla.netfilter.org/show_bug.cgi?id=976 Pablo Neira Ayuso <pablo at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |pablo at netfilter.org --- Comment #1 from Pablo

Add casts to fix these warnings: ./usr/include/linux/netfilter_arp/arp_tables.h:200:19: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/netfilter_bridge/ebtables.h:197:19: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/netfilter_ipv4/ip_tables.h:223:19: error: pointer of type 'void

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. Thanks. Sending latest version of the patch. Now it can seek in files that have large id3 tag (or any random data) at the end and it won't loop on streams with shuffled frames. -- Miroslav Lichvar -------------- next part

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to ?__read_overflow2_field? declared with attribute warning: detected read beyond

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

On Tue, Apr 09, 2013 at 04:39:14PM -0700, Jeff Jia wrote: > Hi, > > I have been using clang for quite a while, and I can use `clang -fno-builtin > hello.c` to prevent the generation of llvm built-in functions, such as > llvm.memset. Recently, I switched to gcc with DragonEgg, since the program to > be built is originally designed to be compiled with gcc. I searched on the web,

Hi chenwj, Thanks! I have tried it, but the generated byte code still uses `llvm.memset`. I guess the flag `-fno-builtin` is not used by DragonEgg, or I missed some other configuration parameters. On Tue, Apr 9, 2013 at 7:45 PM, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw > wrote: > On Tue, Apr 09, 2013 at 04:39:14PM -0700, Jeff Jia wrote: > > Hi, > > > > I have

Hi, I have figured out a way to achieve similar effects. gcc -S -c -O0 -fplugin=$(DRAGONEGG_SO) -fplugin-arg-dragonegg-emit-ir hello.c -o hello.bc opt -O3 -disable-simplify-libcalls hello.bc -o hello.bc On Wed, Apr 10, 2013 at 12:54 PM, Jeff Jia <fjia at cs.ucsd.edu> wrote: > Hi chenwj, > > Thanks! I have tried it, but the generated byte code still uses >

On Fri, 2012-04-27 at 14:54 -0500, Hal Finkel wrote: > There is a comment in the file which reads: > > /* The weird 'i#*X' constraints on the following suppress a gcc > warning when __excepts is not a constant. Otherwise, they mean the > same as just plain 'i'. */ [sinp] > ("mtfsb0 %s0" : : "i#*X"(__builtin_ffs (__excepts))); [snip]

Peter, Could you please comment on: http://llvm.org/bugs/show_bug.cgi?id=12757 Specifically, gcc seems to allow this: int __flt_rounds() { unsigned long fpscr; __asm__ volatile("mffs %0" : "=f"(fpscr)); return fpscr; } My reading of this is that gcc allocates a floating-point register to hold the result of the mffs instruction, and then bit casts (and truncates?) the

On Dec 29, 2009, at 3:09 AM, Heyu Zhu wrote: > Hi everyone, > > I try to add an instruction to x86. The instruction is a multiply-add instruction > MULADD A, B, C; //A = A + B * C. > I use the instruction by inline assemble as below > > int x, y, z; > ..... .... > x = 0; > asm("MULADD %0, %1, %2":"=r"(x):"0"(x), "r"(y),

Take a look at the sources, hmac.h declares struct hmac_context: struct hmac_context { char ctx[HMAC_MAX_CONTEXT_SIZE]; char ctxo[HMAC_MAX_CONTEXT_SIZE]; const struct hash_method *hash; }; If compiled for a 32 bit virtual address space, this has an alignment requirement of 4 due to the hash pointer. In line 171 of auth-token.c, we have following