MDEV-11349 (2/2) Fix some bogus-looking Valgrind warnings
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.)
Showing
Please register or sign in to comment