Re: [Libunwind-devel] Is there a bug fixed in performance optimisations for fast trace?

[Lassi Tuura]

Hi,

> I recently found a confusion in a commit of src/x86_64/Ginit.c.
> URL:http://git.savannah.gnu.org/cgit/libunwind.git/commit/?h=v1.0-stable&id=ae5c1f2adf4da04235d87d024d4d942c01b2b447
> 
> There is a revision as following:
> -      if (c && c->validate && validate_mem(addr))
> +      if (likely (c != 0) && unlikely (c->validate)
> +          && unlikely (validate_mem (addr)))
> 
> The if logic will have a different result while the c->validate is zero.
> Is there a bug fixed here or I have a misunderstanding.
> 
> I am looking forward to your reply. Thank you!

Could you clarify what you mean by 'different result', or how the
meaning changed to be a bug? likely/unlikely(x) translate into
__builtin_expect((x), 0/1), which is documented to evaluate to 'x'.

I'm a little weary eyed for tonight, but stripping likely/unlikely
seems to translate to the same 'if' condition to me.

At any rate, that particular patch was not supposed to change meaning,
so if there's a bug, could you please submit a patch? If you have an
easy way of replicating that problem that would be nice too.

Regards,
Lassi