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.

Reply via email to