In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Using clang for Windows is not tested or suggested. Thus low priority.

Thanks for your help @gniibe and apologies for wasting your time. It looks like this is an issue with ncurses on musl systems and I'll pursue it there. I have a patch to their configure which works & fixes building pinentry.

I've reported it on bug-ncurses@ to get some insight: https://marc.info/?l=ncurses-bug&m=166268018624805&w=2.

Mysteriously, I get nothing:

$ pkg-config --cflags nurses

Could you please check what pkg-config --cflags ncurses returns?
In my environment (of Debian), it returns:

Thanks. QGpgME should now also compile with strict C++11. And C++14'isms shouldn't happen again unnoticed.

Also in:

Thanks for the report! Should be fixed.

Yet another identify theft scam committed by clang.

Problem with clang and these files was resolved by replacement of assembler macros with C preprocessor macros.

That might be helpful. But, on the other hand, if I had just googled the problem I was seeing I would have gotten answer quite fast.

Should we add this to the hints in the README? After all this does not seem to be the standard system compiler or it has not been properly setup as replacement.

Problem was that my build system was selecting "ar" and "ranlib", where as your build system selects "llvm-ar" and "llvm-ranlib".

In T5255#141976, @jukivili wrote:

Unfortunately these are not enough to enable building with clang LTO. Build now fails when linking test executables (libgcrypt.so gets build however):

Any ideas what might be causing this?

Configure output has still has some differences LTO vs non-LTO:

--- non-lto.log 2021-01-21 22:25:14.966099577 +0200
+++ lto.log     2021-01-21 22:25:23.174086100 +0200
@@ -63,7 +63,7 @@
 checking for archiver @FILE support... @
 checking for strip... strip
 checking for ranlib... ranlib
-checking command to parse /usr/bin/nm -B output from clang object... ok
+checking command to parse /usr/bin/nm -B output from clang object... failed
 checking for sysroot... no
 checking for mt... mt
 checking if mt is a manifest tool... no
@@ -75,7 +75,7 @@
 checking if clang static flag -static works... yes
 checking if clang supports -c -o file.o... yes
 checking if clang supports -c -o file.o... (cached) yes
-checking whether the clang linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
+checking whether the clang linker (/usr/bin/ld) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... no
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
@@ -168,8 +168,8 @@
 checking whether 'asm' assembler keyword is supported... yes
 checking whether '__asm__' assembler keyword is supported... yes
 checking whether inline assembly memory barrier is supported... yes
-checking whether GCC assembler is compatible for ARM assembly implementations... no
-checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... no
+checking whether GCC assembler is compatible for ARM assembly implementations... yes
+checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... yes
 checking whether GCC assembler supports for CFI directives... yes
 checking whether GCC assembler supports for ELF directives... yes
 checking for _ prefix in compiled symbols... no
@@ -240,7 +240,7 @@
 checking if gcc supports -Wno-missing-field-initializers... yes
 checking if gcc supports -Wpointer-arith... yes
 checking whether non excutable stack support is requested... yes
-checking whether assembler supports --noexecstack option... yes
+checking whether assembler supports --noexecstack option... no
 checking that generated files are newer than configure... done
 configure: creating ./config.status
 config.status: creating Makefile

Clang support Intel syntax after all, but not assembler macros that were used. Here's two patches that fix the configure.ac issue and removes use of assembly macros in Intel syntax assembly files:

Breakage appears to happen in configure.ac. When building with clang without LTO following check gives "no":

Both are affected. I updated to reflect that I tested the newer version

Closing due to compiler error.

No, it's not. It still misses "-O" entirely.

It's solved!

The fixed sed expression still does not work correctly; it misses the plain "-O" form of the option. As per gcc docs, -O is the same as -O1, and clang accepts it (and the build falls over with it) even though it does not document it at all.

The warning is just a warning, so no problem. The pragma even indicates the compiler for which it is intended.

I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:

With an integer overflow.

This is a standard dynamic sized array:

Sorry, this is a standard C feature and the only way to have dynamic sized arrays. CLANG simply does not get this pattern right. Grep for pgut001's very comments on such ill behaving compilers (including gcc).

At a meta level, I really think that writing more conservative code that enables compilers to do a better job checking for safety is a good idea. The tricks we do with structs are premature optimization from a time when compilers were dumb as a doornail.

Maybe casting to a void* helps to disable the check in the compiler.

I can replicate the issue on my system.
It is not the line 681, actually.

I think that the problem is in your usage with your tool. Please have a look at md_open function in cipher/md.c.
This bug is not the one in libgcrypt, but in the compiler.

Same argument can apply to MD5. See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int' of SHA2.

See T3245: cipher-gcm-intel-pclmul.c:418:17: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long').

See T3248: mpiutil.c:501:37: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' for unsigned integer overflow.

It is intentionally used.
And in the C programming language, it is defined that unsigned integer never overflows (it is computed as modulo 2).

See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int'.

Fixed in git for gnupg 1.4.13, Libgcrypt 1.5.1 and Libgcrypt 1.6.0.

The reason why I was not able to replicate this bug was that
I didn't use -std=c99 with gcc >= 4.3.

See my comments for T1406. It is clearly a clang bug.