ANNOUNCE: p11-kit 0.9

Stef Walter stefw at
Fri Dec 23 03:28:04 PST 2011

I gave up trying to build a custom gcc track this down, but here's my
thinking, and what I did to get around it:

 * The optimization bug seems to be in gcc 4.6.1, and is triggered
   in a corner case.
 * The bug seems to be fixed in 4.6.2.
 * I've rearranged the testing code so the bug is no longer triggered
   on gcc 4.6.1

How does that sound? Acceptable?



On 12/14/2011 07:08 PM, Andreas Metzler wrote:
> On 2011-12-14 Stef Walter <stefw at> wrote:
>> On 2011-12-10 11:06, Andreas Metzler wrote:
> [...]
>>> The minimal change I found was to just build CuFailInternal() without
>>> optimization, by setting
>>> __attribute__((optimize("O0")))
>>> static void CuFailInternal(CuTest* tc, const char* file, int line,
>>> CuString* string)
>> Hmmm, I can see this behavior now. If I slightly rearrange any code it
>> goes away, and that's why it may be that the above seemingly unrelated
>> change fixes the issue.
>> What's happening is that in the test__p11_hash_set_get_clear() gcc is
>> reordering function calls. The line _p11_hash_clear() is running after
>> the last _p11_hash_get() call, even though it's located before it. I've
>> verified this with output to stderr :(
>> So I'm a bit stuck, not sure if I should just refactor the tests to get
>> around the obviously broken compiler, or should I try and take this
>> upstream? Trying to track down where...
>> The gcc version that I can replicate the issue on is "Ubuntu/Linaro
>> 4.6.1-9ubuntu3".
> [...]
> Hello,
> FWIW I have tried reporting this to the Debian bts
> (bug report cced)
> cu andreas
> _______________________________________________
> p11-glue mailing list
> p11-glue at



More information about the p11-glue mailing list