search for: tablesize

...================================================ --- wasm/Writer.cpp (revision 330555) +++ wasm/Writer.cpp (working copy) @@ -257,7 +257,7 @@ raw_ostream &OS = Section->getStream(); writeUleb128(OS, 1, "table count"); - WasmLimits Limits = {WASM_LIMITS_FLAG_HAS_MAX, TableSize, TableSize}; + WasmLimits Limits = {0, TableSize, TableSize}; writeTableType(OS, WasmTable{WASM_TYPE_ANYFUNC, Limits}); } May be to have a code more readable WASM_LIMITS_FLAG_HAS_NO_MAX (=0) can be added. Thks, Ghis 2018-06-03 23:45 GMT+02:00 Sam Clegg <sbc at google.com>: > Hi...

...le. So I am wondering if the static size of the table have a specific goal ? If not did you think the WASM_LIMITS_FLAG_HAS_MAX can be remove ? https://llvm.org/svn/llvm-project/lld/trunk/wasm/Writer.cpp void Writer::createTableSection() { .. WasmLimits Limits = {WASM_LIMITS_FLAG_HAS_MAX, TableSize, TableSize}; Thks in advance, Ghis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180601/ff3ced7a/attachment-0001.html>

> Since the jmp is a fixed 2 bytes (0xEB, tablesize), all references to the table can still be done with trivial pc/RIP-relative addressing within the closure, and you just need one pointer for both the table and the closure data. Only if tablesize fits in 127 bytes. Otherwise it will use 0xE9-based encoding which is larger. -- With best regards,...

....text .align 8 .globl Main_main1_info .type Main_main1_info, @object Main_main1_info: .Lc1Df: jmp .Ltmp .long Main_main1_srt-(Main_main1_info)+0 .long 0 .quad 4294967299 .quad 0 .quad 270582939663 .Ltmp: leaq -8(%rbp),%rax cmpq %r15,%rax jb .Lc1Dh Since the jmp is a fixed 2 bytes (0xEB, tablesize), all references to the table can still be done with trivial pc/RIP-relative addressing within the closure, and you just need one pointer for both the table and the closure data. If you want to get extra special and tricky, you could be even more devious by storing "Main_main1_info + 2 + tabl...

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

I have a problem building an extension using ISNAN() on R version 2.0.x. In R 1.9.1 Arith.h and Rmath.h contained code like #ifdef IEEE_754 # define ISNAN(x) (isnan(x)!=0) #else # define ISNAN(x) R_IsNaNorNA(x) #endif #define R_FINITE(x) R_finite(x) int R_IsNaNorNA(double); int R_finite(double); which works. R 2.0.x has # define ISNAN(x) (isnan(x)!=0) unconditionally. This breaks

Maybe security related mails should be sent elsewhere? I didn't notice any so here it goes: sender.c:receive_sums() s->count = read_int(f); .. s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count); if (!s->sums) out_of_memory("receive_sums"); for (i=0; i < (int) s->count;i++) { s->sums[i].sum1 = read_int(f);

> > Since the jmp is a fixed 2 bytes (0xEB, tablesize), all references to > the table can still be done with trivial pc/RIP-relative addressing within > the closure, and you just need one pointer for both the table and the > closure data. > Only if tablesize fits in 127 bytes. Otherwise it will use 0xE9-based > encoding which is larger....

...------- next part -------------- --- match.c 3 Jan 2004 19:28:03 -0000 1.60 +++ match.c 27 Jan 2004 17:04:22 -0000 @@ -75,8 +75,12 @@ static void build_hash_table(struct sum_ qsort(targets,s->count,sizeof(targets[0]),(int (*)())compare_targets); +#ifdef WEIRD_MINUS_ONE for (i = 0; i < TABLESIZE; i++) tag_table[i] = NULL_TAG; +#else + memset((char *)tag_table, 0xFF, TABLESIZE * sizeof *tag_table); +#endif for (i = s->count; i-- > 0; ) tag_table[targets[i].t] = i;

Hmm writing a blog post about TNTC is beyond the time I have right now. Here is some high level documentation of the layout of Heap objects in GHC: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables With TNTC enabled we generate code for closures of this form: .text .align 8 .long Main_main1_srt-(Main_main1_info)+0 .long 0 .quad 4294967299 .quad 0

...Main_main1_info: > .Lc1Df: > jmp .Ltmp > .long Main_main1_srt-(Main_main1_info)+0 > .long 0 > .quad 4294967299 > .quad 0 > .quad 270582939663 > .Ltmp: > leaq -8(%rbp),%rax > cmpq %r15,%rax > jb .Lc1Dh > > > Since the jmp is a fixed 2 bytes (0xEB, tablesize), all references to the table can still be done with trivial pc/RIP-relative addressing within the closure, and you just need one pointer for both the table and the closure data. > > If you want to get extra special and tricky, you could be even more devious by storing "Main_main1_info...

...t; .long Main_main1_srt-(Main_main1_info)+0 > .long 0 > .quad 4294967299 > .quad 0 > .quad 270582939663 > .Ltmp: > leaq -8(%rbp),%rax > cmpq %r15,%rax > jb .Lc1Dh > > > Since the jmp is a fixed 2 bytes (0xEB, tablesize), all references to the table can still be done with trivial pc/RIP-relative addressing within the closure, and you just need one pointer for both the table and the closure data. > > If you want to get extra special and tricky, you could be even more devious by storing "Main_main1_info +...

Hi list, and Wayne in particular, It was almost a year since we had the discussion (with http://lists.samba.org/archive/rsync/2005-March/011875.html as it's conclusion) regarding chances for hash collisions and large files. As now we have someone asking about synching 5TB files, I decided to actually submit a patch. Attached is a patch that uses a non-predetermined hash table size, so that

FYI, looks like support for Racoon is ending. Does anyone have any experience with the version in ipsec-tools ? ---Mike >Racoon users, > >This is the announcement that the kame project will quit providing >a key management daemon, the racoon, and that "ipsec-tools" will become >the formal team to release the racoon. >The final release of the racoon in the

Hi, I recently came across a situation where "rsync --inplace" performs very poorly. If both the source and destination files contain long sequences of identical blocks, but not necessarily in the same location, the sender can spend an inordinate amount of CPU time finding matching blocks. In my case, I came across this problem while backing up multi-hundred-gigabyte MySQL database

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

...on (1): wined3d: Don't report filtering for WINED3DFMT_R32F. Dan Hipschman (15): rpcrt4/tests: Free memory from one of the tests. widl: Use new functions need_proxy and need_stub to clean up code and avoid generating unnecessary files. widl: Output the correct value for TableSize in ProxyFileInfo. widl: Improve file cleanup when errors occur. widl: Generate dlldata files. widl: Remove printf format strings that aren't really format strings. widl: Detect conformant arrays of user types correctly. widl: Fix problems with variable-size user ty...