https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109290
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2023-03-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- dropping -fno-delete-null-pointer-checks avoids these diagnostics ... because we actually diagnose # VUSE <.MEM_4(D)> val_8 = MEM[(u64 *)0B + -416B]; and that would have been isolated/removed by isolate-paths. <bb 2> [local count: 1073741824]: _1 = &MEM[(struct btrfs_space_info *)kobj_3(D) + -584B].lock; if (_1 != 0B) goto <bb 4>; [53.47%] else goto <bb 3>; [46.53%] <bb 3> [local count: 499612072]: val_8 = MEM[(u64 *)0B + -416B]; goto <bb 5>; [100.00%] <bb 4> [local count: 574129753]: _raw_spin_lock (_1); val_10 = MEM[(u64 *)kobj_3(D) + -416B]; _raw_spin_unlock (_1); <bb 5> [local count: 1073741824]: # val_11 = PHI <val_8(3), val_10(4)> _12 = sysfs_emit (buf_5(D), "%llu\n", val_11); _13 = (long int) _12; return _13; and that's because we call btrfs_show_u64(&sinfo->disk_used, &sinfo->lock, buf); and btrfs_show_u64 does static ssize_t btrfs_show_u64(u64 *value_ptr, spinlock_t *lock, char *buf) { u64 val; if (lock) spin_lock(lock); val = *value_ptr; if (lock) spin_unlock(lock); return sysfs_emit(buf, "%llu\n", val); } again the array-bounds diagnostic isn't very helpful - a -Wnull-dereference diagnostic would be more helpful here. And yes, we thread the double if (lock) here. Without -fno-delete-null-pointer-checks we optimize the function to <bb 2> [local count: 1073741824]: _9 = &MEM[(struct btrfs_space_info *)kobj_3(D) + -584B].lock; _raw_spin_lock (_9); val_10 = MEM[(u64 *)kobj_3(D) + -456B]; _raw_spin_unlock (_9); _12 = sysfs_emit (buf_5(D), "%llu\n", val_10); _13 = (long int) _12; return _13; If you enable -Wnull-dereference (and disable -fno-delete-null-pointer-checks) you get all these cases diagnosed: In function 'to_fs_info', inlined from 'btrfs_discard_kbps_limit_store' at fs/btrfs/sysfs.c:542:34: fs/btrfs/sysfs.c:1318:10: warning: potential null pointer dereference [-Wnull-dereference] fs/btrfs/sysfs.c:1318:10: warning: potential null pointer dereference [-Wnull-dereference] ... so it's really a sign of bad coding / abstraction. Again confirmed because the diagnostic from -Warray-bounds isn't very helpful in pointing out the possible problem.