Hi, Andy,
> For reference. Why does it show up with no-asm? bn_nist.c is collection
> of functions for specific moduli, but it's perfectly possible to
> calculate the result using general-purpose subroutines. It was found
> that general-purpose *assembly* code paths deliver better performance
> and it was arranged so that bn_nist is not invoked in asm builds (look
> for #if defined(OPENSSL_BN_ASM_MONT) in crypto/ec/ec_cvt.c).
If "Configure" invoke without "no-asm" flag, then bn_nist.c compiled, but
function BN_nist_mod_{192,224,256,384} don't called. If "Configure" invoke with
"no-asm", OpenSSL use BN_nist_mod_{192,224,256,384} functions. Right?
--
Sorry for my bests English.
Serguei E. Leontiev w:+7(495)939-2382 USSR,Moscow,Universitetskij 13
Sternberg Astronom. w:+7(495)780-4820 USSR,Moscow,127018,Sushchevskij val 16-5
Institute, MSU h:+7(495)318-1146 USSR,Moscow,113303,Kakhovka 6-40
m:+7(916)686-1081 SMS: <http://www.mts.ru/sms>
<http://lnfm1.sai.msu.ru/~leo>
13.02.2013, в 15:19, Andy Polyakov via RT <[email protected]> написал(а):
> Hi,
>
> Please, reply and keep replying to [email protected], so that proceedings
> are kept together.
>
>> Probably this "strict aliasing" 64-bit optimization bug for
>> "crypto/bn/bn_nist.c"
>>
>> Mac OSX compiler fail test/ectest: cc [Apple LLVM version 4.2
>> (clang-425.0.24) (based on LLVM 3.2svn)] gcc-mp-4.3 gcc-mp-4.4 gcc-mp-4.5
>> gcc-mp-4.6 clang-mp-3.0 clang-mp-3.1 clang-mp-3.2
>>
>> Mac OSX compiler test/ectest OK: gcc-apple-4.2 gcc-mp-4.7 gcc-mp-4.8
>> [gcc-mp-4.8 (MacPorts gcc48 4.8-20130203_0+universal) 4.8.0 20130203
>> (experimental)] clang-mp-2.9 clang-mp-3.3 [clang version 3.3 (trunk 173279)]
>
> In other words it's at least obvious that it varies with compiler
> version. One can argue about where the bug is, compiler or bn_nist.c,
> but it's not matter of probability. Anyway as I can't reproduce the
> problem you'd have to assist.
>
> For reference. Why does it show up with no-asm? bn_nist.c is collection
> of functions for specific moduli, but it's perfectly possible to
> calculate the result using general-purpose subroutines. It was found
> that general-purpose *assembly* code paths deliver better performance
> and it was arranged so that bn_nist is not invoked in asm builds (look
> for #if defined(OPENSSL_BN_ASM_MONT) in crypto/ec/ec_cvt.c).
>
>> After patch:
>
> Could you test following *instead*? In every #if defined(NIST_INT64)
> section you'll see a number of references to bp[something]. Can you
> replace them with buf.ui[samething] and run the test? Currently bp is
> constified buf.ui and it might give overeager compiler idea to reorder
> references to buf in #if defined(NIST_IN64) section and [inlined]
> nist_cp_bn_0 and cause the mayhem.
>
>> $ diff -u ../openssl-SNAP-20130212/crypto/bn/bn_nist.c crypto/bn/bn_nist.c
>> --- ../openssl-SNAP-20130212/crypto/bn/bn_nist.c 2013-01-11
>> 18:13:43.000000000 +0400
>> +++ crypto/bn/bn_nist.c 2013-02-12 13:51:12.000000000 +0400
>> @@ -421,7 +421,7 @@
>>
>> nist_cp_bn_0(buf.bn, a_d + BN_NIST_192_TOP, top - BN_NIST_192_TOP,
>> BN_NIST_192_TOP);
>>
>> -#if defined(NIST_INT64)
>> +#if defined(NIST_INT64) && (BN_BITS2!=64 || defined(NO_BUG_CLANG_GCC_64BIT))
>> {
>> NIST_INT64 acc; /* accumulator */
>> unsigned int *rp=(unsigned int *)r_d;
>> @@ -701,7 +701,7 @@
>>
>> nist_cp_bn_0(buf.bn, a_d + BN_NIST_256_TOP, top - BN_NIST_256_TOP,
>> BN_NIST_256_TOP);
>>
>> -#if defined(NIST_INT64)
>> +#if defined(NIST_INT64) && (BN_BITS2!=64 || defined(NO_BUG_CLANG_GCC_64BIT))
>> {
>> NIST_INT64 acc; /* accumulator */
>> unsigned int *rp=(unsigned int *)r_d;
>> @@ -906,7 +906,7 @@
>>
>> nist_cp_bn_0(buf.bn, a_d + BN_NIST_384_TOP, top - BN_NIST_384_TOP,
>> BN_NIST_384_TOP);
>>
>> -#if defined(NIST_INT64)
>> +#if defined(NIST_INT64) && (BN_BITS2!=64 || defined(NO_BUG_CLANG_GCC_64BIT))
>> {
>> NIST_INT64 acc; /* accumulator */
>> unsigned int *rp=(unsigned int *)r_d;
>>
>>
>> Mac OSX compiler fail test/ectest: gcc-mp-4.3 gcc-mp-4.4 gcc-mp-4.5
>> gcc-mp-4.6
>>
>> Mac OSX compiler test/ectest OK: cc [Apple LLVM version 4.2 (clang-425.0.24)
>> (based on LLVM 3.2svn)] gcc-apple-4.2 gcc-mp-4.7 gcc-mp-4.8 [gcc-mp-4.8
>> (MacPorts gcc48 4.8-20130203_0+universal) 4.8.0 20130203 (experimental)]
>> clang-mp-2.9 clang-mp-3.0 clang-mp-3.1 clang-mp-3.2 clang-mp-3.3 [clang
>> version 3.3 (trunk 173279)]
>>
>>
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [email protected]
> Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
