Description of problem: See https://github.com/openwall/john/issues/4604 I'm on Fedora 33 x64, doing a Fedora 34 x64 mock build for john 1.9.0-Jumbo-1-464-gc9825e688. F34 has gcc 11: # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20210210 (Red Hat 11.0.0-0) (GCC) The rpm spec file uses these build commands: cd src ./configure --disable-rexgen --enable-asan make clean make %{?_smp_mflags} The error: gcc -DAC_BUILT -mavx2 -DJOHN_AVX2 -c -g -Og -fsanitize=address -m64 -I/usr/local/include -DARCH_LITTLE_ENDIAN=1 -DPREFER_FLOCK -Wall -fno-omit-frame-pointer -Wno-deprecated-declarations -Wunused-but-set-variable -std=gnu89 -Wdate-time -D_POSIX_SOURCE -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -fopenmp -pthread -I/usr/local/include -DCL_SILENCE_DEPRECATION -funroll-loops argon2_encoding_plug.c -o argon2_encoding_plug.o In file included from argon2_core_plug.c:32: blake2.h:112:5: error: size of array element is not a multiple of its alignment 112 | blake2b_state S[4][1]; | ^~~~~~~~~~~~~ blake2.h:113:5: error: size of array element is not a multiple of its alignment 113 | blake2b_state R[1]; | ^~~~~~~~~~~~~ make[1]: *** [Makefile:1592: argon2_core_plug.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/builddir/build/BUILD/john-1.9.0.jumbo.1/src' make: *** [Makefile:190: default] Error 2 Steps to reproduce Install a Fedora 33 machine. Install mock You can reproduce it by using the repo https://gitlab.com/fhuberts/rpmsUpstream.git at commit 315a54e. This repo needs a checkout of https://gitlab.com/fhuberts/rpmbuilder.git alongside it. You have rpmbuilder and rpmsUpstream in the same directory. Next you do cd ./rpmsUpstream/fedora/john And then ../buildRPMs -M /etc/mock/fedora-34-x86_64.cfg rpm.spec
Probably caused by <https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=50bc94898fac1bd9cc1dabf227208fb5d369c4c4>. May be a package bug.
That is a package bug. Let's look at simple example: __attribute__((aligned (64))) typedef struct foo { char a; } foo; __attribute__((aligned (64))) typedef struct bar { char a[72]; } bar; int c[] = { sizeof (foo), __alignof (foo), sizeof (struct foo), __alignof (struct foo), sizeof (bar), __alignof (bar), sizeof (struct bar), __alignof (struct bar) }; foo a[2]; bar b[2]; GCC has been rejecting forming an array of foo from ~ GCC 4.0 from early 2006, but is rejecting the latter only since GCC 11. Both have the same problem though, that those typedefs define overaligned types where the size of those types (which is necessarily equal to the size of the corresponding struct) is not an integral multiple of the alignment. When you construct an array of such objects, you are asking for something impossible, while the first array element perhaps can satisfy the alignment by having the whole declaration aligned that way, the second element which must immediately follow the first element can't satisfy that alignment. When it hasn't been rejected, if it "worked", it was by pure luck, the restrictions have been added because when not so lucky code accessing such array elements didn't work at all. If you comment out the a/b array definitions, you can see that the c array contains 1, 64, 1, 1, 72, 64, 72, 1. The question is what exactly you want to achieve. One possibility is you want already the structs to be aligned that way, then the fix is to put the attribute to the right spot. E.g. typedef struct __attribute__((aligned (64))) foo { char a; } foo; typedef struct __attribute__((aligned (64))) bar { char a[72]; } bar; will do that. c array will then be: 64, 64, 64, 64, 128, 64, 128, 64 and the testcase will compile, you can form such arrays just fine because the size is integral multiple of the alignment. Or you shouldn't create arrays of foo and bar, but instead of struct foo and struct bar which have the normal ABI alignment requirements. And if you want to ensure particular alignment of the start of those arrays, do: typedef struct foo foo2[2] __attribute__((aligned (64))); typedef struct bar bar2[2] __attribute__((aligned (64))); foo2 a; bar2 b; etc.
Thanks for the quick responses, and very good explanation!
Thank you