mirror of
https://github.com/MariaDB/server.git
synced 2025-01-31 19:11:46 +01:00
a68d1352b6
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.) |
||
|---|---|---|
| .. | ||
| buf0buddy.cc | ||
| buf0buf.cc | ||
| buf0checksum.cc | ||
| buf0dblwr.cc | ||
| buf0dump.cc | ||
| buf0flu.cc | ||
| buf0lru.cc | ||
| buf0mtflu.cc | ||
| buf0rea.cc | ||