> I need the Integer dev-branch tested. The Integer class is usually solid,
> but a couple of platforms have intermittent trouble with it. The
> "intermittent trouble" is a sign of undefined behavior. You usually see its
> effects when the self tests hang on the BlumBlumShub test.
>
We were able to zero-in on the issue. It seems GCC was eliding a
constructor (I think that's what happened) due to our [non-legal] use of a
union in C++. Effectively we have a DWord class with:
struct half_words
{
word64 low;
word64 high;
};
struct DWord
{
DWord(word64 low, word64 high)
{
m_halfs.low = low;
m_halfs.high = high;
}
...
union
{
# if WORD128_AVAILABLE
word128 m_whole;
#endif
half_words m_halfs;
};
};
GCC was generating code to use the m_whole because a 128-bit word was
available, so we needed to initialize it and make it the active member:
# if WORD128_AVAILABLE
DWord(word64 low, word64 high) : word128()
#else
DWord(word64 low, word64 high) : word64()
#endif
{
m_halfs.low = low;
m_halfs.high = high;
};
More details with the diff can be found at
http://github.com/weidai11/cryptopp/issues/293 .
The extra value initialization cost us 2-3% in performance, but it clears a
Coverity finding and initializes the DWord class properly.
We still need thorough testing, but it looks good on our first pass with
GCC, Clang, MSC and SunCC.
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
