mirror of
https://github.com/MariaDB/server.git
synced 2025-01-23 15:24:16 +01:00
d247d64988
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.) |
||
|---|---|---|
| .. | ||
| api | ||
| btr | ||
| buf | ||
| data | ||
| dict | ||
| eval | ||
| fil | ||
| fsp | ||
| fts | ||
| fut | ||
| gis | ||
| ha | ||
| handler | ||
| ibuf | ||
| include | ||
| lock | ||
| log | ||
| mach | ||
| mem | ||
| mtr | ||
| mysql-test/storage_engine | ||
| os | ||
| page | ||
| pars | ||
| que | ||
| read | ||
| rem | ||
| row | ||
| srv | ||
| sync | ||
| trx | ||
| usr | ||
| ut | ||
| CMakeLists.txt | ||
| compile-innodb | ||
| COPYING.Google | ||
| COPYING.Percona | ||
| innodb.cmake | ||
| plugin_exports | ||