On Jan 29, 2014, at 4:28 AM, İsmail Dönmez <[email protected]> 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.
> [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.
Thanks,
Jason
_______________________________________________
jemalloc-discuss mailing list
[email protected]
http://www.canonware.com/mailman/listinfo/jemalloc-discuss
