# git rev-parse -q --verify d5f6545934c47e97c0b48a645418e877b452a992^{commit}
d5f6545934c47e97c0b48a645418e877b452a992
already have revision, skipping fetch
# git checkout -q -f -B kisskb d5f6545934c47e97c0b48a645418e877b452a992
# git clean -qxdf
# < git log -1
# commit d5f6545934c47e97c0b48a645418e877b452a992
# Author: Linus Torvalds <torvalds@linux-foundation.org>
# Date:   Mon Sep 20 10:26:21 2021 -0700
# 
#     qnx4: work around gcc false positive warning bug
#     
#     In commit b7213ffa0e58 ("qnx4: avoid stringop-overread errors") I tried
#     to teach gcc about how the directory entry structure can be two
#     different things depending on a status flag.  It made the code clearer,
#     and it seemed to make gcc happy.
#     
#     However, Arnd points to a gcc bug, where despite using two different
#     members of a union, gcc then gets confused, and uses the size of one of
#     the members to decide if a string overrun happens.  And not necessarily
#     the rigth one.
#     
#     End result: with some configurations, gcc-11 will still complain about
#     the source buffer size being overread:
#     
#       fs/qnx4/dir.c: In function 'qnx4_readdir':
#       fs/qnx4/dir.c:76:32: error: 'strnlen' specified bound [16, 48] exceeds source size 1 [-Werror=stringop-overread]
#          76 |                         size = strnlen(name, size);
#             |                                ^~~~~~~~~~~~~~~~~~~
#       fs/qnx4/dir.c:26:22: note: source object declared here
#          26 |                 char de_name;
#             |                      ^~~~~~~
#     
#     because gcc will get confused about which union member entry is actually
#     getting accessed, even when the source code is very clear about it.  Gcc
#     internally will have combined two "redundant" pointers (pointing to
#     different union elements that are at the same offset), and takes the
#     size checking from one or the other - not necessarily the right one.
#     
#     This is clearly a gcc bug, but we can work around it fairly easily.  The
#     biggest thing here is the big honking comment about why we do what we
#     do.
#     
#     Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c6
#     Reported-and-tested-by: Arnd Bergmann <arnd@kernel.org>
#     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
# < /opt/cross/kisskb/korg/gcc-11.1.0-nolibc/m68k-linux/bin/m68k-linux-gcc --version
# < /opt/cross/kisskb/korg/gcc-11.1.0-nolibc/m68k-linux/bin/m68k-linux-ld --version
# < git log --format=%s --max-count=1 d5f6545934c47e97c0b48a645418e877b452a992
# < make -s -j 32 ARCH=m68k O=/kisskb/build/linus_m68k-defconfig_m68k-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/m68k-linux/bin/m68k-linux-  defconfig
# < make -s -j 32 ARCH=m68k O=/kisskb/build/linus_m68k-defconfig_m68k-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/m68k-linux/bin/m68k-linux-  help
# make -s -j 32 ARCH=m68k O=/kisskb/build/linus_m68k-defconfig_m68k-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/m68k-linux/bin/m68k-linux-  olddefconfig
# make -s -j 32 ARCH=m68k O=/kisskb/build/linus_m68k-defconfig_m68k-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/m68k-linux/bin/m68k-linux-  
Completed OK
# rm -rf /kisskb/build/linus_m68k-defconfig_m68k-gcc11
# Build took: 0:01:26.577184