macOS M1: dilithium/aarch64 not compiling with gcc

[bhess]

Describe the bug
Compiling fails on macOS (M1) when using gcc.

...
[ 63%] Building ASM object src/sig/dilithium/CMakeFiles/dilithium_2_aarch64.dir/pqclean_dilithium2_aarch64/__asm_iNTT.S.o
/Users/bhe/git/liboqs/src/sig/dilithium/pqclean_dilithium2_aarch64/__asm_iNTT.S:8:1: error: unknown directive
.type PQCLEAN_DILITHIUM2_AARCH64_asm_intt_SIMD_top, %function
^
/Users/bhe/git/liboqs/src/sig/dilithium/pqclean_dilithium2_aarch64/__asm_iNTT.S:418:1: error: unknown directive
.type PQCLEAN_DILITHIUM2_AARCH64_asm_intt_SIMD_bot, %function
^
...

To Reproduce
Steps to reproduce the behavior:

cmake -DCMAKE_C_COMPILER=gcc-13 ..
make

Environment (please complete the following information):

• OS: macOS 13.4.1
• OpenSSL version 1.1.1t
• Compiler version used: gcc-13 (Homebrew GCC 13.1.0) 13.1.0
• Build variables used "-DCMAKE_C_COMPILER=gcc-13"
• liboqs version: main

Additional context
The respective ".type , %function" statements in the aarch64 assembly code are excluded for clang but not for gcc:

liboqs/src/sig/dilithium/pqclean_dilithium2_aarch64/__asm_iNTT.S

Lines 7 to 9 in 93e7847

	#ifndef __clang__
	.type PQCLEAN_DILITHIUM2_AARCH64_asm_intt_SIMD_top, %function
	#endif

PQClean upstream appears to have removed the ".type , %function" statements in the meanwhile, so a fresh copy_from_upstream might help.

[baentsch]

We anyway need a fresh pull to retrieve the license updates your colleagues are looking for in #1437 -- but for ease-of-doing, I'd recommend holding that to after #1470 landed.

[baentsch]

@bhess #1470 has landed. Did I read the above right in that you volunteer(ed) to do the PR to close this issue?

[bhess]

Sure, I'll do a pull tomorrow and see if it fixes the issue.

[baentsch]

@bhess Thanks in advance. And while you're at it, please also check clang operations: I'm now getting an error on M1 in AES, too (plain cmake -GNinja .. config): The code was introduced in 719a84e

[9/652] Building C object src/common/CMakeFiles/common.dir/aes/aes256_armv8.c.o
FAILED: src/common/CMakeFiles/common.dir/aes/aes256_armv8.c.o 
/Library/Developer/CommandLineTools/usr/bin/cc -DOQS_HAVE_ALIGNED_ALLOC -DOQS_HAVE_GETENTROPY -DOQS_HAVE_MEMSET_S -DOQS_HAVE_POSIX_MEMALIGN -I/Users/baentsch/git/liboqs/build/include -std=gnu11 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.4 -fPIC -fvisibility=hidden -march=armv8-a+crypto -Wall -Wextra -Wpedantic -Wno-unused-command-line-argument -Wa,--noexecstack -O3 -fomit-frame-pointer -Wbad-function-cast -Wcast-qual -Wnarrowing -Wconversion -Werror -mcpu=cortex-a53+crypto -MD -MT src/common/CMakeFiles/common.dir/aes/aes256_armv8.c.o -MF src/common/CMakeFiles/common.dir/aes/aes256_armv8.c.o.d -o src/common/CMakeFiles/common.dir/aes/aes256_armv8.c.o -c /Users/baentsch/git/liboqs/src/common/aes/aes256_armv8.c
/Users/baentsch/git/liboqs/src/common/aes/aes256_armv8.c:73:84: error: cast from 'const void *' to 'aes256ctx_nobitslice *' drops const qualifier [-Werror,-Wcast-qual]
        const unsigned char *schedule = (const unsigned char *) ((aes256ctx_nobitslice *) _schedule)->sk_exp;

[bhess]

@bhess Thanks in advance. And while you're at it, please also check clang operations: I'm now getting an error on M1 in AES, too (plain cmake -GNinja .. config): The code was introduced in 719a84e

Thanks for catching this @baentsch. I could reproduce the error but needed to compile with cmake -GNinja -DOQS_USE_AES_OPENSSL=OFF -DCMAKE_C_FLAGS="-Werror" ... Will add a fix with the PR!