Fix GCC 12 and Clang 15 compilation errors

[szubersk]

Motivation and Context

Make the code compile on Ubuntu 22.10 (Kinetic).

Description

• Squelch false positives reported by GCC 12 with UBSan.
• Clang 15 doesn't support -fno-ipa-sra anymore. Do a separate
  check for -fno-ipa-sra support by $KERNEL_CC.
• Don't enable -mgeneral-regs-only for certain module files.
  Fix Unable to compile on ARM64 with clang #13260
• Scope GCC diagnostic ignored statements to GCC only. Clang
  doesn't need them to compile the code.

How Has This Been Tested?

make

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[szubersk]

@behlendorf @ryao Errors suppressed in this PR are false positives reported by GCC. Unfortunately, new GCC versions bring them along occasionally.

[ryao]

@szubersk I am already using the newer GCC on Gentoo. I am confused why I am not seeing the same build failures. If we could figure out what is different between Gentoo and Ubuntu, maybe we could find another way of handling this.

[ryao]

https://bugs.gentoo.org/847148

I thought that the difference might be that Gentoo is not yet using _FORTIFY_SOURCE=3, but building with CFLAGS='-O2 -D_FORIFY_SOURCE=3' does not trigger the issue. I also tried CFLAGS='-O3 -D_FORIFY_SOURCE=3' and that produced a clean build too. I verified that the CFLAGS were being passed to GCC by building with make V=1. :/

I tried installing a Ubuntu 22.10 userland locally by doing as root:

zfs create -o mountpoint=/mnt/ubuntu22.10 rpool/ROOT/ubuntu22.10

debootstrap --include=vim,wget,gpg kinetic /mnt/ubuntu22.10 http://archive.ubuntu.com/ubuntu/

wget -O /mnt/ubuntu22.10/etc/apt/sources.list https://gist.githubusercontent.com/ishad0w/2187a4eaab9273387645ac11905aca68/raw/ae20b6e9c8e987081d6c15b9085b549505ea85e8/sources.list

sed -i -e 's/jammy/kinetic/g' /mnt/ubuntu22.10/etc/apt/sources.list

cp {,/mnt/ubuntu22.10}/etc/resolv.conf

mkdir /mnt/ubuntu22.10/mnt/host

sudo -i unshare -m
pivot_root /mnt/ubuntu22.10 /mnt/ubuntu22.10/mnt/host
mount --bind {/mnt/host,}/proc
mount --bind {/mnt/host,}/sys
mount --bind {/mnt/host,}/dev/pts
mount --bind {/mnt/host,}/dev/shm
exec bash -i
cd /root

apt update

apt install build-essential autoconf automake libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev linux-headers-generic python3 python3-dev python3-setuptools python3-cffi libffi-dev python3-packaging git libcurl4-openssl-dev

git clone https://github.com/openzfs/zfs

cd zfs

./autogen.sh && ./configure --enable-debug --enable-debuginfo --with-config=user && make -j$(nproc)

This should have reproduced at least one of your failures since you posted that the compiler emitted CC lib/libnvpair/libnvpair_la-libnvpair.lo right before printing error messages, but I have a clean build. :/

Note that I had to package debootstrap version 1.0.128 for Gentoo locally before it would install Ubuntu 22.10.

Some quick commands verify that my local Ubuntu userland is the correct version for 22.10:

root@vserver:~/zfs# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.10
Release:        22.10
Codename:       kinetic
root@vserver:~/zfs# gcc -v |& grep 'gcc version'
gcc version 12.2.0 (Ubuntu 12.2.0-3ubuntu1)

I even tried forcing _FORTIFY_SOURCE=3 and verified that I was forcing it, but that did not trigger build failures either.

That leaves me with the question: What is special about the build environment on your Ubuntu 22.10 installation that is triggering these build failures?

[ryao]

@szubersk One thing that stands out to me is that dpkg-query says that I have gcc 4:12.2.0-1ubuntu1, but gcc -v claims to be 12.2.0-3ubuntu1. What version does gcc -v report for you?

[szubersk]

@szubersk One thing that stands out to me is that dpkg-query says that I have gcc 4:12.2.0-1ubuntu1, but gcc -v claims to be 12.2.0-3ubuntu1. What version does gcc -v report for you?

ubuntu@vm:~/zfs-clang$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.2.0-3ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Ubuntu 12.2.0-3ubuntu1) 

ubuntu@vm:~/zfs-clang$ dpkg-query --show gcc libc6
gcc  4:12.2.0-1ubuntu1
libc6:amd64     2.36-0ubuntu4

[ryao]

In that case, I am not sure what is different.

Would you try running the commands I gave for how I made my Ubuntu 22.10 environment and see if this still reproduces for you in that environment? You would need to install debootstrap, but you can substitute a mkdir command in place of the zfs command. Run sudo -i by itself to get a root shell to use to run the commands.

Edit: It occurs to me that pivot_root will not be happy if you use mkdir instead of the zfs command since it wants an actual mountpoint. You can probably make a bind mount to “mount” another directory at that location to workaround that. That said, pivot_root is just a fancy alternative to chroot, so you could substitute chroot in place of pivot_root and it should be just as good.

[szubersk]

In that case, I am not sure what is different.

Would you try running the commands I gave for how I made my Ubuntu 22.10 environment and see if this still reproduces for you in that environment? You would need to install debootstrap, but you can substitute a mkdir command in place of the zfs command. Run sudo -i by itself to get a root shell to use to run the commands.

Edit: It occurs to me that pivot_root will not be happy if you use mkdir instead of the zfs command since it wants an actual mountpoint. You can probably make a bind mount to “mount” another directory at that location to workaround that. That said, pivot_root is just a fancy alternative to chroot, so you could substitute chroot in place of pivot_root and it should be just as good.

Sure, I'll reproduce the build process exactly as you wrote and let's compare results then.

[szubersk]

@ryao turns out that the differentiator is ASan/UBSan. GCC changes its behavior if those flags are on. When they are not set I can't observe the issue either. Please try changing the configure invocation to

./configure --enable-debug --enable-debuginfo --enable-asan --enable-ubsan

[ryao]

@ryao turns out that the differentiator is ASan/UBSan. GCC changes its behavior if those flags are on. When they are not set I can't observe the issue either. Please try changing the configure invocation to

./configure --enable-debug --enable-debuginfo --enable-asan --enable-ubsan

It turns out that reproducing this only needs --enable-ubsan. --enable-asan does not emit any errors. Interestingly, building with CC=clang does not emit any warnings with --enable-ubsan, but then linking fails unless --enable-asan is specified. This seems to be another bug. I also tried CC=gcc-11.3.1, which fails with:

module/icp/algs/blake3/blake3.c: In function 'compress_parents_parallel':
module/icp/algs/blake3/blake3.c:288:9: error: 'parents_array' may be used uninitialized [-Werror=maybe-uninitialized]
  288 |         ops->hash_many(parents_array, parents_array_len, 1, key, 0, B_FALSE,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  289 |             flags | PARENT, 0, 0, out);

Presumably, builds with --enable-ubsan and the latest versions of GCC have been broken for a while and nobody noticed until now.

I would like to study this a little more in depth, but my time this week is incredibly tight, so I cannot spend much more time on it right now. However, the inconsistency in send_print_verbose() bothers me and the complaint in zio_crypt_key_init() is a compiler bug.

My feeling is that both the zio_crypt_key_init() issue and all instances where fprintf() causes a warning should be reported to GCC so that they are addressed since keeping quiet about them could mean that we will need to work around an increasingly buggy compiler. However, I realize that making the minimal test cases for GCC is a bunch of work in itself.

That said, I would like to request the following changes:

• Break this into two commits. One would be for Clang and the other would be for GCC.
• The GCC commit message should document that this is for recent versions of GCC when building with --enable-ubsan.
• Rather than doing #if defined(__GNUC__) && !defined(__clang__), we should do #if defined(__GNUC__) && !defined(__clang__) && ((!defined(_KERNEL) && defined (ZFS_UBSAN_ENABLED)) || defined(CONFIG_UBSAN)). This would be whenever GCC + ubsan complains.

Someone would need to test it to be certain, but I suspect that builds against Linux kernels built with CONFIG_UBSAN=y would also have an issue, which is why I am preemptively suggesting that we check for that, while leaving builds without UBSAN enabled without these hacks. That should at least make it a little more clear that we are working around a GCC compiler issue involving UBSAN and hopefully encourage one of us to send bug reports to GCC.

[ryao]

• Rather than doing #if defined(__GNUC__) && !defined(__clang__), we should do #if defined(__GNUC__) && !defined(__clang__) && ((!defined(_KERNEL) && defined (ZFS_UBSAN_ENABLED)) || defined(CONFIG_UBSAN)). This would be whenever GCC + ubsan complains.

It occurs to me that this will miss the case that someone is passing -fsanitize=undefined manually via CFLAGS and LDFLAGS, but given that we have gone so long without anyone reporting this issue, we are probably safe to assume that no one does that. I had wanted to suggest a way to detect UBSAN directly via toolchain defined preprocessor definitions, but variations of echo | gcc -dM -E - do not show a way to do that. I imagine that we could inspect the CFLAGS given to us for -fsanitize=undefined in our configure script and set ZFS_UBSAN_ENABLED to do the right thing, but I am not going to ask you to do that here.

The compiler warnings are harmless unless --enable-debug is set to force -Werror and I strongly doubt anyone is likely to hit the magic combination that will cause build failures. That is especially since --enable-debug is currently broken on Gentoo and no one but me complained (I wrote a patch that is in the future 2.1.7 release to fix that).

[thesamesam]

It's common for sanitizers to affect diagnostics (and whether or not a bug even occurs) because the instrumentation affects code generation a fair bit sometimes.

It would be worth reporting a bug to GCC about this if you think the warning is bogus.

[ryao]

It would be worth reporting a bug to GCC about this if you think the warning is bogus.

Unfortunately, doing a good bug report against a compiler has significant enough overhead that it is difficult to file reports for every bug. I have discovered this the hard way with LLVM/Clang’s static analyzer. They want minimal test cases and sometimes, when you make a minimal test case, things are wrong in some other way that is just enough for the compiler authors to say that there is no bug, when the compiler clearly has a bug when run on the original code, but your attempt at cutting out all irrelevant code somehow cut out something important for reproducing the bug. Trying to get it right is a tedious process. Another possibility is getting sucked into a long drawn out conversation about the standard where some ridiculous decision by the standard’s committee to label something that clearly has known behavior as undefined results in a heated disagreement over whose code needs to change to correct the bug. I have experienced both scenarios first hand. :/

I do not blame others for not volunteering to go through that process. It is a huge time drain.

[thesamesam]

Sure, I'm suggesting it as someone who has been through it several times too. It's taken several days on a single bug before. It doesn't change that we don't want an unbounded number of compiler workarounds building up in ZFS.

At the very least should be able to submit a preprocessed version even if not reduced.

[ryao]

Sure, I'm suggesting it as someone who has been through it several times too. It's taken several days on a single bug before. It doesn't change that we don't want an unbounded number of compiler workarounds building up in ZFS.

That is a fair point. I would like to find a volunteer to do this too. Sadly, I cannot be that volunteer as I have no spare bandwidth to handle a compiler bug report right now.

[behlendorf]

@szubersk this seems to be ready. If you don't have any additional changes planned I can get it merged.

[szubersk]

I'm all ready, merely rebasing after recent surge of merges to master.

Thanks @behlendorf !