mersenneforum.org > EdH How I install YAFU onto my Ubuntu Machines
 Register FAQ Search Today's Posts Mark Forums Read

 2020-03-23, 17:35 #56 bsquared     "Ben" Feb 2007 1100110110102 Posts Ok, thanks. If you are willing, you could try (independently) older versions of ecm and gmp. That might help pinpoint where the incompatibility occurred.
2020-03-23, 18:36   #57
RedGolpe

Aug 2006
Monza, Italy

22·3·5 Posts

Quote:
 Originally Posted by bsquared It may be more productive to move forward in yafu releases rather than backward because the more-recent stuff is more likely to work with more-recent versions of dependent libraries.
Indeed. Again, thank you for your time.

So I downloaded the wip version, modified the relevant files (note that Makefile attempts to run "gcc-7.3.0", which I edited in just "gcc"). Also, running make with the flag x86_64 did not work:
Code:
redgolpe@c2018:~/yafu$make x86_64 NFS=1 SKYLAKEX=1 USE_BMI2=1 USE_AVX2=1 make: *** No rule to make target 'x86_64'. Stop. Running with all other flags it works correctly and... yay! No fragmentation faults. Please let me know if I can help in any other way.  2020-03-23, 18:39 #58 EdH "Ed Hall" Dec 2009 Adirondack Mtns 3×5×223 Posts How disappointing! I had saved, in tact, all my directories for gmp, ecm, msieve, ggnfs and yafu. (Actually I did nothing with the ggnfs directory.) I then made new installations for all. But, now that I have gone back to the original gmp, ecm, msieve and yafu directories and reinstalled gmp and ecm via "sudo make install," the previously working yafu segmentation faults. I even tried a previous copy of a compiled yafu that I've been using in a totally different directory and it segfaults. YAFU was running fine today prior to my experiments, so it has to be something that changed today, but did not change back. More later. . .  2020-03-23, 18:52 #59 RedGolpe Aug 2006 Monza, Italy 22·3·5 Posts If this can be of any use, I'm fine with yafu v1.35-beta, GMP-ECM 7.0.5-dev, GMP 6.2.0, Msieve v. 1.54 (SVN 1030) compiled with gcc 7.5.0 on Ubuntu 18.04.4 LTS. I have not (yet) installed the ggnfs libraries (nor ggnfs). Last fiddled with by RedGolpe on 2020-03-23 at 18:53 2020-03-23, 19:17 #60 EdH "Ed Hall" Dec 2009 Adirondack Mtns 3×5×223 Posts Quote:  Originally Posted by RedGolpe If this can be of any use, I'm fine with yafu v1.35-beta, GMP-ECM 7.0.5-dev, GMP 6.2.0, Msieve v. 1.54 (SVN 1030) compiled with gcc 7.5.0 on Ubuntu 18.04.4 LTS. I have not (yet) installed the ggnfs libraries (nor ggnfs). That sounds good that you're now up and running with the wip branch. I will try a total upgrade with wip here, but I've got an i5 Haswell (I believe) machine, so it might be a bit different. An identical machine is running 16.04 and is fine with gmp 6.1.2 and ecm 7.0.5 with the trunk branch of YAFU. I hesitate to play with that one and break it. For now I'll play with trying to get this broken one back to working. Thanks for the info.  2020-03-23, 21:14 #61 RedGolpe Aug 2006 Monza, Italy 22·3·5 Posts I spoke too soon. While I was able to run "tune" after installing the ggnfs binaries, the frag fault has returned on a C89. At least it looks like the problem is reproducible as only specific numbers seem to trigger it. Code: >> factor(2^295+97) fac: factoring 63657374260452690195888927762793067532858387302060507832379389042324415617604272068231265 fac: using pretesting plan: normal fac: using specified qs/gnfs crossover of 93 digits fac: using specified qs/snfs crossover of 75 digits div: primes less than 10000 Segmentation fault (core dumped) Even factoring 2 does not work: Code: >> factor(2) fac: factoring 2 fac: using pretesting plan: normal fac: using specified qs/gnfs crossover of 93 digits fac: using specified qs/snfs crossover of 75 digits div: primes less than 10000 Segmentation fault (core dumped) But the problem does not seem related to small factors only: 2^274+97 fails too despite its smallest factor being a P33. On the other hand, the "tune" C80 succeeds, and also does 3528253658491813 * 790674939293910225420845660353. Contrary to the previous installation, now when the factorization does fail, it seems to do so immediately. There is no noticeable delay between my pressing ENTER and the error message. Last fiddled with by RedGolpe on 2020-03-23 at 21:37  2020-03-23, 21:41 #62 EdH "Ed Hall" Dec 2009 Adirondack Mtns D1116 Posts My machine is working again, with GMP 6.1.2, GMP-ECM 7.0.5, and the trunk branch of YAFU. However, AVX2 segfaults, while SSE4.1 runs fine. Basically, I uninstalled GMP and GMP-ECM, then removed all relative directories and recreated everything (except ggnfs) based on this thread. I will try to do some more testing tomorrow and post another update. 2020-03-23, 21:47 #63 EdH "Ed Hall" Dec 2009 Adirondack Mtns 3×5×223 Posts Quote:  Originally Posted by RedGolpe I spoke too soon. While I was able to run "tune" after installing the ggnfs binaries, the frag fault has returned on a C89. At least it looks like the problem is reproducible as only specific numbers seem to trigger it. Code: >> factor(2^295+97) fac: factoring 63657374260452690195888927762793067532858387302060507832379389042324415617604272068231265 fac: using pretesting plan: normal fac: using specified qs/gnfs crossover of 93 digits fac: using specified qs/snfs crossover of 75 digits div: primes less than 10000 Segmentation fault (core dumped) Even factoring 2 does not work: Code: >> factor(2) fac: factoring 2 fac: using pretesting plan: normal fac: using specified qs/gnfs crossover of 93 digits fac: using specified qs/snfs crossover of 75 digits div: primes less than 10000 Segmentation fault (core dumped) But the problem does not seem related to small factors only: 2^274+97 fails too despite its smallest factor being a P33. On the other hand, the "tune" C80 succeeds, and also does 3528253658491813 * 790674939293910225420845660353. Contrary to the previous installation, now when the factorization does fail, it seems to do so immediately. There is no noticeable delay between my pressing ENTER and the error message. I ran the number several times with my current setup (explained in my previous post) and all ran smooth through factoring.  2020-03-23, 22:04 #64 RedGolpe Aug 2006 Monza, Italy 3C16 Posts Attempting make with various flags except AVX2 fails for me. For example: Code: make NFS=1 SKYLAKEX=1 USE_BMI2=1 results in Code: factor/qs/SIQS.o: In function process_poly': /home/redgolpe/yafu/factor/qs/SIQS.c:870: undefined reference to nextRoots_32k_avx2_small' factor/qs/SIQS.o: In function siqs_static_init': /home/redgolpe/yafu/factor/qs/SIQS.c:1642: undefined reference to nextRoots_32k_avx2' /home/redgolpe/yafu/factor/qs/SIQS.c:1677: undefined reference to med_sieveblock_32k_avx2' /home/redgolpe/yafu/factor/qs/SIQS.c:1733: undefined reference to tdiv_medprimes_32k_avx2' /home/redgolpe/yafu/factor/qs/SIQS.c:1734: undefined reference to resieve_medprimes_32k_avx2' /home/redgolpe/yafu/factor/qs/SIQS.c:1685: undefined reference to med_sieveblock_32k_sse41' /home/redgolpe/yafu/factor/qs/SIQS.c:1650: undefined reference to nextRoots_32k_sse41' /home/redgolpe/yafu/factor/qs/SIQS.c:1685: undefined reference to med_sieveblock_32k_sse41' /home/redgolpe/yafu/factor/qs/SIQS.c:1710: undefined reference to tdiv_medprimes_32k_avx2' /home/redgolpe/yafu/factor/qs/SIQS.c:1734: undefined reference to resieve_medprimes_32k_avx2' factor/qs/SIQS.o: In function printf': /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: undefined reference to tdiv_medprimes_32k_avx2' factor/qs/SIQS.o: In function siqs_static_init': /home/redgolpe/yafu/factor/qs/SIQS.c:1650: undefined reference to nextRoots_32k_sse41' collect2: error: ld returned 1 exit status Makefile:359: recipe for target 'all' failed make: *** [all] Error 1 and Code: make NFS=1 USE_BMI2=1 results in Code: In file included from /usr/lib/gcc/x86_64-linux-gnu/7/include/immintrin.h:41:0, from include/soe.h:27, from top/eratosthenes/primes.c:15: /usr/lib/gcc/x86_64-linux-gnu/7/include/avxintrin.h:926:1: error: inlining failed in call to always_inline ‘_mm256_storeu_si256’: target specific option mismatch _mm256_storeu_si256 (__m256i_u *__P, __m256i __A) ^~~~~~~~~~~~~~~~~~~ top/eratosthenes/primes.c:586:17: note: called from here _mm256_storeu_si256((__m256i *)(&primes[GLOBAL_OFFSET + pcount]), t); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/lib/gcc/x86_64-linux-gnu/7/include/immintrin.h:41:0, from include/soe.h:27, from top/eratosthenes/primes.c:15: /usr/lib/gcc/x86_64-linux-gnu/7/include/avxintrin.h:920:1: error: inlining failed in call to always_inline ‘_mm256_loadu_si256’: target specific option mismatch _mm256_loadu_si256 (__m256i_u const *__P) ^~~~~~~~~~~~~~~~~~ top/eratosthenes/primes.c:585:25: note: called from here __m256i t = _mm256_loadu_si256((__m256i *)(&pqueues[i][j*4])); ^ In file included from /usr/lib/gcc/x86_64-linux-gnu/7/include/immintrin.h:41:0, from include/soe.h:27, from top/eratosthenes/primes.c:15: /usr/lib/gcc/x86_64-linux-gnu/7/include/avxintrin.h:926:1: error: inlining failed in call to always_inline ‘_mm256_storeu_si256’: target specific option mismatch _mm256_storeu_si256 (__m256i_u *__P, __m256i __A) ^~~~~~~~~~~~~~~~~~~ top/eratosthenes/primes.c:586:17: note: called from here _mm256_storeu_si256((__m256i *)(&primes[GLOBAL_OFFSET + pcount]), t); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/lib/gcc/x86_64-linux-gnu/7/include/immintrin.h:41:0, from include/soe.h:27, from top/eratosthenes/primes.c:15: /usr/lib/gcc/x86_64-linux-gnu/7/include/avxintrin.h:920:1: error: inlining failed in call to always_inline ‘_mm256_loadu_si256’: target specific option mismatch _mm256_loadu_si256 (__m256i_u const *__P) ^~~~~~~~~~~~~~~~~~ top/eratosthenes/primes.c:585:25: note: called from here __m256i t = _mm256_loadu_si256((__m256i *)(&pqueues[i][j*4])); ^ Makefile:369: recipe for target 'top/eratosthenes/primes.o' failed make: *** [top/eratosthenes/primes.o] Error 1 Last fiddled with by RedGolpe on 2020-03-23 at 22:04 2020-03-24, 15:34 #65 bsquared "Ben" Feb 2007 2×5×7×47 Posts Quote:  Originally Posted by RedGolpe Indeed. Again, thank you for your time. So I downloaded the wip version, modified the relevant files (note that Makefile attempts to run "gcc-7.3.0", which I edited in just "gcc"). Also, running make with the flag x86_64 did not work: Code: redgolpe@c2018:~/yafu$ make x86_64 NFS=1 SKYLAKEX=1 USE_BMI2=1 USE_AVX2=1 make: *** No rule to make target 'x86_64'. Stop. Running with all other flags it works correctly and... yay! No fragmentation faults. Please let me know if I can help in any other way.
Good! Glad that worked out. Even more incentive (as if I needed it) for me to get the wip branch merged back into trunk. Based on this and possibly EdH's trials it appears that trunk might no longer be compatible with the most-recent gmp or ecm somehow. EdH if you produce data supporting this it would be cool to hear it.

2020-03-24, 15:53   #66
RedGolpe

Aug 2006
Monza, Italy

22×3×5 Posts

Quote:
 Originally Posted by bsquared Glad that worked out.
Actually it didn't as the seg fault reappeared with new factorizations: see the following messages. As I said, it even fails with factor(2) which should be a good target for debugging: if I can help in any way, please let me know.

 Similar Threads Thread Thread Starter Forum Replies Last Post EdH EdH 3 2019-06-24 03:42 EdH EdH 12 2019-04-16 09:28 EdH EdH 0 2018-02-23 14:43 EdH EdH 0 2018-02-22 03:31 EdH EdH 0 2018-02-21 23:48

All times are UTC. The time now is 16:40.

Sun Sep 20 16:40:29 UTC 2020 up 10 days, 13:51, 1 user, load averages: 1.16, 1.14, 1.15