self-check failure

[Stef Walter]

On 2012-03-19 20:28, Simon Josefsson wrote:
> mån 2012-03-19 klockan 18:31 +0100 skrev Stef Walter:
>> On 2012-03-09 15:06, Simon Josefsson wrote:
>>> Stef Walter<stefw at gnome.org>   writes:
>>>
>>>> On 2012-03-09 14:46, Simon Josefsson wrote:
>>>>> Thanks for 0.12. :-)  However I got a self-test failure when running
>>>>> 'make check':
>>>>>
>>>>> make[2]: Entering directory `/home/jas/src/p11-kit-0.12/tests'
>>>>> 0x402f57 setting
>>>>> ....F........
>>>>>
>>>>> There was 1 failure:
>>>>> 1) test_set_clear: hash-test.c:182: should be null
>>>>
>>>> Which version of GCC are you using?
>>>
>>> This is a pretty vanilla Debian Squeeze amd64 system.
>>
>> I installed Debian Squeeze to reproduce this. I've seen a similar
>> problem before. It looks like a gcc optimization bug. If you configure
>> like so:
>>
>> CFLAGS='-O0' ./configure
>>
>> then the problem does not occur.
>>
>> In your opinion what should we do? I have a hard time distilling this
>> into a test case to send to the gcc development guys. When I make
>> changes, the issue dissappears.
>
> Until someone has time to debug this further, I would be inclined to
> just let the self-test prints (when it fails) that the failure may be
> because of a suspected compiler bug and point to the mailing list
> archive for this discussion.

What's happening is that the _p11_hash_clear() and _p11_hash_get() 
functions in hash-test.c lines 179 and 181 are being called in inverse 
order.

> Do you think the miscompilation is likely to affect how my build works?
> If it is a critical piece of code failing, you may want to print more
> warnings that the library must not be used if it fails the checks.

We can recommend that the library is built with -O0 if the tests fail.

>> Previously I think we saw the issue with gcc 4.6.1. I made trivial
>> changes [1] to suppress the issue with that gcc release. I thought it
>> was specific to that point release. However it appears that the problem
>> is more widespread :(
>
> Hm, 4.6.1 is pretty modern, so chances are that this affects the latest
> gcc version as well, which may make gcc people more interested in
> debugging this.  However, they probably don't want to spend too much
> time distilling this into a test case.

It doesn't affect 4.7.x and last time I checked it didn't affect 4.6.2 
either. So that's why I hoped that this had been fixed.

Cheers,

Stef