how to build on macos x86_64

[hellok]

ifndef SIGCLD
define SIGCLD SIGCHLD
endif
solved

2.src/mont/fp_montgomery_reduce.c:514:15: error: unknown register name '%cc' in
asm
INNERMUL8;

[buggywhip]

I too am encountering the same problem. (affects fp_montgomery_reduce.c, fp_mul_comba.c, and fp_sqr_comba.c)

The only reference I find to CC is WRT Motorola's 68K processors. Actually it is CCR (Condition Code Register) and some have since chosen to shorten it to just CC. Suspecting it is a "leftover"...

I simply removed the references to "%cc" found under the switch "X86_64" in each of the three affected files. I built the library including the provided program "test". Running test revealed no errors.

Not knowing whether this fix would be applicable to all processors I did not generate a patch. Perhaps someone with ARM, MIPS, etc experience can make that determination.

[buggywhip]

Correction to above post: I meant to say switch "TFM_X86_64", not "X86_64".

[danfe]

While gcc accepts %cc and %memory, the syntax is wrong, since % is only used for registers. Clang currently rejects these bogus constructs (and that's fine).

Similar fix was applied to NSS by Mozilla team before.

[sjaeckel]

I've applied the patches and tfm compiles now with gcc and clang

can someone verify that this also fixes the build problems on mac os?

[buggywhip]

On Jun 14, 2014, at 3:20 AM, Larry Bugbee bugbee@mac.com wrote:

For the record, I'm running a 2.53GHz Core2Duo, a P8700.
http://www.cpu-world.com/CPUs/Core_2/Intel-Core%202%20Duo%20Mobile%20P8700%20AW80577SH0613MG%20%28BX80577P8700%29.html

I believe I am using correct flags. ...but am I?

I'm also assuming the 1st Montgomery KAT is correct. ...but is it? Do you know for sure? Perhaps tomorrow I write an independent program to verify.

fp_read_radix(&a, "234892374892374893489123428937892781237863278637826327367637836278362783627836783678363", 10);
fp_read_radix(&b, "4447823492749823749234123489273987393983289319382762756425425425642727352327452374521", 10);
fp_read_radix(&c, "2396271882990732698083317035605836523697277786556053771759862552557086442129695099100", 10);
fp_montgomery_setup(&b, &dp);
fp_montgomery_reduce(&a, &b, dp);
if (fp_cmp(&a, &c)) {
DISPLAY("mont failed\n");
return 0;
} else {
DISPLAY("mont passed\n");
}

My OSX build* of TFM and all tests appear satisfactory, including the two Montgomery tests in demo/test.c, except...

I'm unable to get the 3 Montgomery KATs in demo/stest.c to calculate the expected value under TFM. ...likewise under LTM. (I basically change fp_ to mp_ and link to the other lib.) Nor do the calculated Montgomery values, for both TFM and LTM, agree with each other. Something is very wrong! ???

Does demo/stest.c work for you? What processor and what flags?

Clues? Things I should check?

I'm now in the hunt for another lib with Montgomery to see if I can get anything to agree with anything else.

Larry

build* note: There are some warnings during the compile of demo/test.c similar to this...
demo/test.c:253:50: warning: format specifies type 'unsigned long long' but the argument has type 'ulong64' (aka 'unsigned long') [-Wformat]
printf("%5lu-bit: %9llu\n", t * DIGIT_BIT, t2);
~~~~~ ^~
%9lu

[sjaeckel]

Thanks for trying out @buggywhip
I've seen the same issue with Montgomery and stest yesterday and also tried the same approach and did not succeed with LTM...

But now I tried the 32bit mode on 64bit CPU's with "gcc -m32" and stest succeeds...

I'm running on Linux Mint. Tried gcc 4.7.3 and 4.8.1

Steffen

[buggywhip]

On Jun 14, 2014, at 8:11 PM, Larry Bugbee bugbee@mac.com wrote:

I'm now in the hunt for another lib with Montgomery to see if I can get anything to agree with anything else.

Attached are two programs. The first is a short OpenSSL test program, mr-openssl.c, which looks at the three Montgomery reduction KATs found in stest.c. The second program is a slightly modified version of stest.c that 1) shows the calculated result when a test fails, and 2) doesn't stop so we can see the remaining test cases.

WRT the stest.c KATs, a 64-bit mr-openssl agrees with KAT cases 2 and 3 only. mr-openssl's different result for case 1 is
942974496560863503657226741422301598807235487941674147660989764036913926327577165648

With the exception of the 94297..648 number above, it appears TFM in 64-bit mode agrees with the OpenSSL results. I cannot say the same for 64-bit LTM.

In 64-bit mode, mr-openssl gave the following result.

miniServer:tomsfastmath-master bugs$ mr-openssl

Test case 1
a = 234892374892374893489123428937892781237863278637826327367637836278362783627836783678363
b = 4447823492749823749234123489273987393983289319382762756425425425642727352327452374521
r = 942974496560863503657226741422301598807235487941674147660989764036913926327577165648

Test case 2
a = 2348923748923748934891234456645654645645684576353428937892781237863278637826327367637836278362783627836783678363
b = 444782349274982374923412348927398739398328931938276275642542542564272735232745237452123424324324444121111119
r = 45642613844554582908652603086180267403823312390990082328515008314514368668691233331246183943400359349283420

Test case 3
a = 234823424242342923748923748934891234456645654645645684576353424972378234762378623891236834132352375235378462378489378927812378632786378263273676378362783627555555555539568389052478124618461834763837685723645827529034853490580134568947341278498542893481762349723907847892983627836783678363
b = 44478234927456563455982374923412348927398739398328931938276275642485623481638279025465891276312903262837562349056234783648712314678120389173890128905425242424239784256427
r = 33160865265453361650564031464519042126185632333462754084489985719613480783282357410514898819797738034600484519472656152351777186694609218202276509271061460265488348645081

miniServer:tomsfastmath-master bugs$

[sjaeckel]

wow, thanks!

but attached is ... nothing ... github_issues--

probably we should move this discussion to the ML...
@buggywhip can you please send the mail to the ML?

[sjaeckel]

I just tested the build on Mac OS X 10.12.4 and it works fine from current develop.

Latest release spits some warnings and makefile.shared was broken.

I'm closing this, as it's resolved.