Timespec size compile warning

I’m attempting to build linux from scratch from www.linuxfromscratch.org (which undoubtedly will find issues as that project doesn’t presently support risc-v) and I’ve been building patches for issues I encounter as I move through it. I’m now a bit stuck now since the problem I’m now encountering is pulled in via m4 somehow, and was wondering if anyone already knows about a timespec size issue, or is better than I am at tracing back m4 macros. Here’s the compile warning:

utimens.c: In function 'fdutimens':
utimens.c:383:17: warning: 'update_timespec' accessing 16 bytes in a region of size 8 [-Wstringop-overflow=]
  383 |       if (ts && update_timespec (&st, &ts))
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
utimens.c:383:17: note: referencing argument 2 of type 'struct timespec **'
utimens.c:134:1: note: in a call to function 'update_timespec'
  134 | update_timespec (struct stat const *statbuf, struct timespec *ts[2])
      | ^~~~~~~~~~~~~~~

I know it’s just a warning, but it implies that there is a type size issue which could well be catastrophic. OR… it might be totally benign.

This comes up when compiling ‘gzip’ and also when compiling ‘patch’.

I should mention that I am using linux headers generated from a version of linux created the following way: (1) checkout 5.12.4 (2) apply all meta-sifive patches, (3) merge 5.12.13 (merges suprisingly cleanly), (4) apply any other patch that became necessary.

At this point I’m pretty sure this is a false positive, since the system tools built seem to be working fine. Since I changed my language of choice from C to Rust back in 2014, warnings like this have become a lot more creepy-looking to me.

The stringop-overflow warning is new. It looks like the code declares an array of size two, then casts away the array type to get a plain pointer, and then casts the pointer back to an array of size two. That confuses the stringop-overflow code. The code will work, but it could have cleaner type usage. And maybe the stringop-overflow code could be improved to handle this case better.