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 <email@example.com> 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
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org