[cfe-commits] r166731 - /cfe/trunk/test/CodeGenCXX/catch-undef-behavior.cpp

[Chandler Carruth]

On Thu, Oct 25, 2012 at 11:59 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Oct 25, 2012 at 9:48 PM, Chris Lattner <clattner at apple.com> wrote:
>>
>> On Oct 25, 2012, at 3:27 PM, Richard Smith <richard-llvm at metafoo.co.uk> wrote:
>>
>>> Author: rsmith
>>> Date: Thu Oct 25 17:27:30 2012
>>> New Revision: 166731
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=166731&view=rev
>>> Log:
>>> LLVM's hashing routines produce a size_t, and thus generate different values for 32- and 64-bit host compilers. This really needs to be fixed -- the IR generated should not depend on the host -- but this change will get the bots green again. Proper fix to follow.
>>
>> Codegen shouldn't depend on specific hash values - iteration over densemap (and friends) is considered nondeterministic.  What are you seeing?
>
> Sorry for the imprecision! This sanitizer pass generates uniquish
> numbers for classes by hashing their mangled names, which are then
> emitted into the IR and used to cache the results of an 'is this type
> derived from that type?' query. LLVM's hashing functions produce
> different results on 32- and 64-bit platforms due to their use of
> size_t, resulting in different IR generated in the two different
> cases. The fix here is just to move away from using these hashing
> routines, onto something which produces a more stable unique class ID.

And to add a bit more context here that never made it into email,
Richard and I discussed this, and I suggested explicitly to go ahead
and use the hash_value stuff until we get a nice stable hashing
library in place. It's something on my todo list, and it didn't seem
worth blocking progress. the current algorithm is "good enough" in the
short term, and I'm aware of it so it won't break on accident.


>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits