- 26 5月, 2023 1 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19
-
- 12 4月, 2023 2 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
- 08 3月, 2022 1 次提交
-
-
由 zhao_zhen_zhou 提交于
Signed-off-by: Nzhao_zhen_zhou <zhaozhenzhou@huawei.com>
-
- 17 3月, 2020 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com> (Merged from https://github.com/openssl/openssl/pull/11344)
-
- 17 2月, 2020 1 次提交
-
-
由 David Benjamin 提交于
If one of the perlasm xlate drivers crashes, OpenSSL's build will currently swallow the error and silently truncate the output to however far the driver got. This will hopefully fail to build, but better to check such things. Handle this by checking for errors when closing STDOUT (which is a pipe to the xlate driver). This is the OpenSSL 1.1.1 version of https://github.com/openssl/openssl/pull/10883 and https://github.com/openssl/openssl/pull/10930. Reviewed-by: NMark J. Cox <mark@awe.com> Reviewed-by: NPaul Dale David Benjamin <davidben@google.com> (Merged from https://github.com/openssl/openssl/pull/10931)
-
- 12 11月, 2017 1 次提交
-
-
由 Josh Soref 提交于
Around 138 distinct errors found and fixed; thanks! Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3459)
-
- 13 10月, 2017 1 次提交
-
-
由 Rich Salz 提交于
Names were not removed. Some comments were updated. Replace Andy's address with openssl.org Reviewed-by: NAndy Polyakov <appro@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/4516)
-
- 06 8月, 2016 1 次提交
-
-
由 klemens 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1413)
-
- 21 5月, 2016 1 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 08 3月, 2016 2 次提交
-
-
由 Andy Polyakov 提交于
Make all scripts produce .S, make interpretation of $(CFLAGS) pre-processor's responsibility, start accepting $(PERLASM_SCHEME). [$(PERLASM_SCHEME) is redundant in this case, because there are no deviataions between Solaris and Linux assemblers. This is purely to unify .pl->.S handling across all targets.] Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Richard Levitte 提交于
This gets rid of the BEGINRAW..ENDRAW sections in crypto/bn/build.info. This also moves the assembler generating perl scripts to take the output file name as last command line argument, where necessary. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 06 9月, 2013 1 次提交
-
-
- 29 6月, 2007 1 次提交
-
-
由 Andy Polyakov 提交于
is fixed now.
-
- 20 6月, 2007 1 次提交
-
-
由 Andy Polyakov 提交于
PR: 1547
-
- 18 6月, 2007 1 次提交
-
-
由 Andy Polyakov 提交于
-
- 20 3月, 2007 1 次提交
-
-
由 Andy Polyakov 提交于
for 64-bit alignment was not removed.
-
- 08 12月, 2006 1 次提交
-
-
由 Andy Polyakov 提交于
-
- 28 11月, 2006 4 次提交
-
-
由 Andy Polyakov 提交于
-
由 Andy Polyakov 提交于
-
由 Andy Polyakov 提交于
over 0.9.8 is up to 3x on USI&II cores and up to 80% - on USIII&IV.
-
由 Andy Polyakov 提交于
factor" in inner loops.
-
- 19 12月, 2005 1 次提交
-
-
由 Andy Polyakov 提交于
afford to relax SPARCV9/8+ compiler command line and produce "unversal" binaries as we used to.
-
- 17 12月, 2005 1 次提交
-
-
由 Andy Polyakov 提交于
Engage run-time switch between bn_mul_mont_fpu and bn_mul_mont_int.
-
- 16 12月, 2005 1 次提交
-
-
由 Andy Polyakov 提交于
have impact on performance, because amount of multiplications does not increase with this switch, not on sparcv9 that is. On the contrary, it actually improves performance, because it spares a load of instructions used to chase carries. Not to mention that BN assembler modules can be shared more freely between 32- and 64-bit builts.
-
- 25 10月, 2005 1 次提交
-
-
由 Andy Polyakov 提交于
-
- 23 10月, 2005 2 次提交
-
-
由 Andy Polyakov 提交于
-
由 Andy Polyakov 提交于
-
- 19 10月, 2005 1 次提交
-
-
由 Andy Polyakov 提交于
integrated yet, but it's tested and benchmarked [see commentary section for further details].
-