ANNOUNCE: p11-kit 0.9
stefw at collabora.co.uk
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 collabora.co.uk> wrote:
>> On 2011-12-10 11:06, Andreas Metzler wrote:
>>> The minimal change I found was to just build CuFailInternal() without
>>> optimization, by setting
>>> 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
> FWIW I have tried reporting this to the Debian bts
> http://bugs.debian.org/651595 (bug report cced)
> cu andreas
> p11-glue mailing list
> p11-glue at lists.freedesktop.org
More information about the p11-glue