jemalloc 3.5.0 regressions on i586

[İsmail Dönmez]

Hi,


On Wed, Jan 29, 2014 at 9:09 PM, Jason Evans <jasone at canonware.com> wrote:

> On Jan 29, 2014, at 4:28 AM, İsmail Dönmez <ismail at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20140129/1e879b96/attachment.html>