jemalloc 3.5.0 regressions on i586

[İsmail Dönmez]

Hi,


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

> On Jan 29, 2014, at 11:17 AM, İsmail Dönmez <ismail at donmez.ws> wrote:
>
> 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.
>
>
> Did -fno-optimize-sibling-calls make it through to the compilation
> commands?  If not, try using EXTRA_CFLAGS instead.  Assuming -fno-optimize-sibling-calls
> is actually getting used, I'm out of ideas as to how this is failing, and I
> may need to set up an equivalent environment to dig in further.
>
>
Its there: CFLAGS             : -O2 -fno-optimize-sibling-calls -std=gnu99
-fvisibility=hidden , just removing the -O2 fixes the problem. So its
indeed an optimization problem, so how about compiling the tests with -O0
instead?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20140129/e94b3d32/attachment.html>