Hi,
On Wed, Jan 29, 2014 at 9:09 PM, Jason Evans <jas...@canonware.com> wrote: > On Jan 29, 2014, at 4:28 AM, İsmail Dönmez <ism...@donmez.ws> wrote: > > I have 2 new failures: > > > > thd_start:test/unit/prof_accum.c:83: Failed assertion: > (bt_count_prev+(i-i_prev)) <= (bt_count) --> 6 > 1: thd_start > > I'm guessing that this is due to the compiler being especially intelligent > regarding mutual recursion for alloc_[01](), and I just added noinline > attributes for those functions: > > > https://github.com/jemalloc/jemalloc/commit/526e4a59a2fe39e4f8bdf1ec0c0d2a5a557c3f62 > > However, if the compiler is being that smart, it may also be smart enough > to do tail call optimization despite an attempt in the code to thwart > optimization. It appears that the gcc flag to disable this is > -fno-optimize-sibling-calls, but I'm reluctant to resort to that unless the > noinline attribute fails to do the job. > This one is still failing, also adding -fno-optimize-sibling-calls to CFLAGS didn't fix it. > > > [test_alignment_errors:test/integration/allocm.c:60: Failed assertion: > (allocm(&p, &rsz, sz, (ffs(alignment)-1))) != (0) --> 0 == 0: > test_alignment_errors > > This is the equivalent failure to the mallocx failure you hit before. > Fixed: > > > https://github.com/jemalloc/jemalloc/commit/2850e90d0d42d0e2b54864949bfa41c59c3a8dc9 > > Testing is hard. I am continually amazed by how much variation there is > in compiler warnings and other behaviors, even between minor compiler > revisions. That said, most of the issues you hit are unique to 32-bit > systems, so I really need to set up a 32-bit test system prior to the next > release. > This is working as expected :) Regards.
_______________________________________________ jemalloc-discuss mailing list jemalloc-discuss@canonware.com http://www.canonware.com/mailman/listinfo/jemalloc-discuss
