• Marko Mäkelä's avatar
    MDEV-11349 (2/2) Fix some bogus-looking Valgrind warnings · d247d649
    Marko Mäkelä authored
    buf_block_init(): Initialize buf_page_t::flush_type.
    For some reason, Valgrind 3.12.0 would seem to flag some
    bits in adjacent bitfields as uninitialized, even though only
    the two bits of flush_type were left uninitialized. Initialize
    the field to get rid of many warnings.
    
    buf_page_init_low(): Initialize buf_page_t::old.
    For some reason, Valgrind 3.12.0 would seem to flag all 32
    bits uninitialized when buf_page_init_for_read() invokes
    buf_LRU_add_block(bpage, TRUE). This would trigger bogus warnings
    for buf_page_t::freed_page_clock being uninitialized.
    (The V-bits would later claim that only "old" is initialized
    in the 32-bit word.) Perhaps recent compilers
    (GCC 6.2.1 and clang 4.0.0) generate more optimized x86_64 code
    for bitfield operations, confusing Valgrind?
    
    mach_write_to_1(), mach_write_to_2(), mach_write_to_3():
    Rewrite the assertions that ensure that the most significant
    bits are zero. Apparently, clang 4.0.0 would optimize expressions
    of the form ((n | 0xFF) <= 0x100) to (n <= 0x100). The redundant
    0xFF was added in the first place in order to suppress a
    Valgrind warning. (Valgrind would warn about comparing uninitialized
    values even in the case when the uninitialized bits do not affect
    the result of the comparison.)
    d247d649
buf0buf.cc 178 KB