URL | name ]]URL | name ]]Hi Werner,

Please provide information on how you build this. That is invocation of configure and make and best attsch the created config.log.

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.

According to this, setting LD is not sufficient to make gcc use a different linker.

https://patents.stackexchange.com/questions/5766/is-an-expired-patent-in-the-public-domain

I found US patent which is expired due to fee: https://patents.google.com/patent/US7080109B2/en
The technique is described in : https://koclab.cs.ucsb.edu/docs/koc/j56.pdf
This is related paper: https://koclab.cs.ucsb.edu/docs/koc/j47.pdf

Intel has patent application for folding technique for Montgomery reduction: US8392494
which is described in this paper: https://www.cse.buffalo.edu/srds2009/escs2009_submission_Gopal.pdf

Ah, ok, thanks for the info!

Likely fixed by commit a4d1595a2638db63ac4c73e722c8ba95fdd85ff7 (rijndael-aesni: split assembly block to ease register pressure) in 1.7 branch (and included in 1.7.3+).

I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.

Compiler bug. Probably misdetection of aesni support in old AMD processors?

Intel has patent application for folding technique for Barret reduction: US20070297601
and it is granted as: US8229109

The part of using Simultaneous Multiple Exponentiation (SME) for RSA is not patented, I think.
So, let me consider with SME.

Another area would be faster (constant time) Barrett reduction.

In search of algorithm, I found this slide:
http://www1.spms.ntu.edu.sg/~ccrg/documents/chienning-multiexponentiation.pdf

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'.

No way to test on El Capitain anymore. It works on Sierra.

With the new rndjent as used with libgcrypt 1.8 under Windows rhis can be claimed as finished.

@werner Is it clearer now if gcryptrnd will be removed or ported?

If we will ever do this, then only in conjunction with appropriate continuous integration tools that report on new warnings and progress. Closing here.

and the platform is ...

The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

Applied in rCe0958debe1a7: secmem: Fix SEGV and stat calculation..

Here is a test case:

I had an older version of libgcrypt (1.6.5) in my /usr/local/bin. I removed that version, ran the make check again, and this time got a fail again for random: image not found. I continued the installation, and libgcrypt-1.7.6 successfully (it appears, anyway!) installed.

Patch applied and pushed.

Thanks very much! I have solved the problem.

Please do not post files in closed formats like Microsoft word. We will only
look at reports in a plain text format.

From your description it looks more like a build problem because Libgcrypt is
already part of Ubuntu and installing a different version is possible but you
need to get some things right. In general I would suggest to write to
gcrypt-devel@gnupg.org

Yes, it's the same issue.

Isn't this the same as T2975 ?

Yes, .cpu generic+simd+crypto that what I thought after first patch from the beginning
but didn't test it first, blame me for it. Now it compiles as expected, please include
it into next release.

D410: 957_03-fix-clang-arm64.patch

How about this patch?

No, it still fails, here is fresh log:
http://pkg.krion.cc/data/110arm64-default/2017-02-26_16h58m38s/logs/errors/libgcrypt-
1.7.6.log

Does the attached patch fix the problem?

D411: 956_02-fix-clang-arm64.patch

Ok, thanks!

You need to wait for 1.8 - in a few weeks.
I looked at the required changes but decided not to backport that for 1.7.6.